Get better quality images and stop thinking like a print designer

I admit it, I have a print background. As much as I try to leave that all in the past, it always creeps up and bites me in the ass.

Pixel-based image asset management is a mystery to many in print and in the new purely digital world. What constitutes a quality asset file to be reproduced? In print there are clear rules, but in digital display there are many other variables. This post is a description of my journey in finally figuring this out.

The principles of an image

Regardless of intended output, every image has three primary attributes: pixel width and height, physical width and height, and dpi. Of course there is color space, color profile and a few others, but that is outside the scope of this discussion.

Images and print

In the print world, this was all figured out a long time ago. When printing an image, there is a direct relationship between the physical size of the image and it’s resolution in coloration with the resolution of the printing process, typically referred to as Lines Per Inch, or LPI.

If you want to print an image at 5" x 5", first make sure that the image you want to print is actually that physical size. Resolution depends on the output process.

For example, newspaper printers typically use a process consisting of around 100lpi. The standing rule is that you need twice as much dots per inch in your image as the lines per inch you are printing. So for a 5" x 5" 100lpi print, you need a 5" x 5" 200dpi image.

For a full-color, high-end commercial print, you may see lines per inch as high as 200lpi. Going with the 2x formula and the previous example, you need a 5" x 5" image with 400dpi to print clearly.

In summary, in physical printing, the size of the asset is key and the resolution is dependent on the output.

Images in the web

The rules are much different with images on the screen and the web. First, let’s talk about 72dpi.

The choice of 72 PPI by Macintosh for their displays arose from the convenient fact that the official 72 points-per-inch mirrored the 72 pixels-per-inch that actually appeared on their display screens (1).

This decision had a negative impact on rendering fonts at the poplar 10-point size carried over from typewriters. Microsoft tried to address with the creation of the 96PPI resolution characteristic that is 1/3 times higher then the resolution of the screen. In the end, this addressed the 10-point font issue with Apple, but 10-point fonts appeared as 13-point.

Better technologies, fonts, and vector graphics helped address these issues, but we are still left with great confusion on what the base resolution of a computer is.

Is it 72dpi or 96dpi?

We know 1:96 is a fixed ratio of CSS ‘in’ to CSS ‘px’. For drawing graphics on a screen, 1" = 96px. But this is only a measurement, not a resolution.

Resolution is applied to your screen. Much like the print situation, resolution is dependent out output. With images on the screen, the resolution is your output. Your computer is either using a standard resolution or a hi-dpi (retina) screen. To add more confusion, a 15.4" Macbook pro with retina display with a 2880 x 1800 native resolution will have a resolution of 220PPI. What about 72dpi or 96dpi? This is where we simply understand that there is no longer a 1:1 between the points-per-inch of the OS and the pixels-per-inch in the display. This is referred to as resolution independence (4).

A new measurement spec (2) is dppx, a unit representing the number of dots per px unit. So a 96PPI view is == 1dppx, a 192PPI view is == 2dppx. This is not a physical resolution spec; it’s a CSS resolution spec. A standard def device sees CSS as 96dpi and a retina sees CSS at 192dpi. As confusing as this is, at least there is something that is constant as hardware manufactures are continuing to mess with our heads.

This new measurement can be used in a media query as illustrated in this device pixel density test.

The dpi of an image asset when presented to the screen is meaningless. I know, crazy! Paint programs such as Photoshop have made us believe that ‘web safe’ images are 72dpi, but I am finding that to be false.

DPI is meaningless to the web

Here is where this gets a little weird. As I have been saying, dpi has no bearing when it comes to an image you want to present on the web. You can push up an image that has a dpi of 10 and it will look awesome.

What really matters is the pixel width and height of the image. The relationship gets weird when an 800px wide and 1123px tall image at 10dpi has a physical size of 80x112.3". That’s right, the image is huge. If you were to print it at that size, it would look horrible. Good thing we aren’t printing it.

The physical size has no relation to the what an inch means on a screen. Like I said, 1" in CSS == 96px or 192px depending on your display. My Macbook pro has a physical resolution of 220PPI; 96 and 192 is a CSS measurement, not a physical measurement. What really matters is the 800x1123px.

A 800x1123 image at 72dpi will produce an image that is 11.111x15.597". Place that image in a page and then place a CSS block under it with width: 11.111in; the CSS block would be wider than the image. Why? It’s the 1:96 rule. 11.111in = 1066.656px. What the browser cares about is 800 / 96 = 8.333333in.

Examples creating a new file in Photoshop

This whole process gets more interesting when we crate a new image in Photoshop. Again, dpi has no impact on the size of the image. It’s physical size that does.

For example, if we have a 800x800px at 96dpi, it equals 1.83M. But if we increase the dpi to 300dpi, leaving the 800x800px, it still equals 1.83M. It’s only when we increase the physical size, be it the inches or the pixel width/height, do we increase file size.

Definition of screen quality

So, with all this in mind, what does it mean to have an image look good in a computer screen?

We have determined that dpi is meaningless, so it doesn’t matter if you save your images at 72dpi or 10dpi. Generally applications like Photoshop will force 72dpi on you as a default setting as a ‘web safe’ export value.

What matters is the pixel size of the asset. I find it a best practice to follow in this new age of retina displays to always start off with art at twice the normal size you intend to display. If you want to display at 400x400px, your asset needs to be 800x800px. Again, dpi doesn’t matter at export, so don’t sweat it.

When including the new asset into the view of your website, you will crunch it down to the desired 400x400px size. I know, for how long now we have all said that for web optimization we need to serve up the image at the size it will be displayed. Well, set that on fire, because times have changed.

But these images are HUGE!

The next concern is that we are now producing large images to send to the client. That’s right, we are. But what we have now and we didn’t have back then is the increased ability to recreate graphics with CSS3 and much faster networks.

This leaves us with just pictures. This ‘squish down’ method is interesting because we are reducing the size of the image pixel to match the device display of hardware pixels. This helps in the reduction of visual artifacts in heavily compressed images.

Let’s take for example a 800x1123px poster image. When I export from Photoshop, I will set the quality to 0, which will give me a 70k file. When I bring this into a web page and display it at its native size, it looks pretty bad, especially on a retina device. When I then reduce the image to display at 400px wide, it looks great. If I go down to 300px wide to target a handheld device, it looks even better.

What about mobile?

You may be thinking, “we can’t send these large images to handheld devices, are you mad?!” An average handheld device download is around 3 megabit per/sec, which roughly equates to 375k per/sec. At 70k, that’s roughly 5 images per second. From these observations, I’m not overly concerned with these numbers.

Sure, when you are targeting a handheld device you may want to send a different sized/cropped image. This is being discussed around the proposed <picture> element (3), but it’s still in discussion and nowhere near a recommendation. Thus, if you are in the mindset that you need to send a different resolution/sized image to a handheld device versus the desktop device, you don’t have to worry about it.


At the end of all of this, what is the final recommendation? If the asset you are adding to the page can be reproduced using CSS, do that first. Next, if the asset is iconic, use ico-fonts or SVGs, as these are not pixel-dependent assets and will look great on any resolution device.

If you do need to send an image asset, follow these steps:

  • Export the asset at twice the pixel width and height you intend to display
  • Don’t worry about dpi, it doesn’t matter
  • Use heavy compression when exporting a .jpg
  • In the HTML attribute or CSS, reduce the size of the image to the desired viewable size.

Custom images based in display type

The only caveat I can think of is if the design actually has a different asset based in the client’s display type. There are two ways you can do this. The first is Webkit’s image-set function, which allows you to set an array of assets with a 1x or 2x designation. Although it is common to see a _2x naming convention, it is not required. The key is the 1x or 2x within the array.

.image-set {
  background: -webkit-image-set(url(images/banner_1x.png) 1x, url(images/banner_2x.png) 2x);
  width: 400px;
  height: 40px;

This function is only currently supported by Chrome, Safari and Opera.

The next thing you can do is use a standard media query like the following:

.image-query {
  background: url(images/banner_1x.png) no-repeat 0 0;
  width: 400px;
  height: 40px;

@media screen and (min-resolution: 2dppx), (-webkit-min-device-pixel-ratio: 1.3) {
  .image-query {
    background: url(images/banner_2x.png);
    background-size: 100%;


This research has put me on a wild ride of learning what’s happening in the world of image assets. So much of what I used to know and understand about images and print is now dead. This is a whole new way of thinking that has been turned on it’s head with the rise of higher resolution devices.

What I thought to be true about 72dpi and it’s relationship to monitor displays, I am now really finding out to be untrue, or at least outdated thinking.

What makes me feel better is now that I know how this works, it is a lot less work to really think about.

Everything I learned is available in this github repo.

Next PostPrevious Post

About the Author