What does DPI mean for images on the web?
By Dan Yoachim · February 2, 2015 · 3 minute read
Dots per inch (DPI) is something you'll see talked about often with images. Put simply, dots per inch is a printing term that refers to how many dots of ink would cross an inch on physical paper. Simple enough. But this isn't relevant for displaying images on screens. False information abounds, and display is complicated enough on its own.
Dots per inch (DPI) is something you’ll see talked about often with images. Put simply, dots per inch is a printing term that refers to how many dots of ink would cross an inch on physical paper.
So, if your image has 10x10 dots at 10dpi, its 1 square inch. At 5dpi, its 2 square inches. Simple enough. This number isn’t relevant for displaying images on screens. I bring it up because its important understand why that is. False information abounds, and display is complicated enough on its own.
Unlike dots on paper, on a screen the pixels are fixed. ‘Printing’ 10 ‘dots’ is the same distance every time, because 10 slots are always 10 slots. Both the 5dpi and 10dpi versions of an image will display identically digitally.
What we really need is an images resolution, something like 30x20 pixels. That way we know the image will fill 30 horizontal pixels by 20 vertical pixels, a guaranteed size! So, to deliver the best image, the resolution should match the container size exactly.
But alas, not all is as it seems. Though css pixels and screen pixels began at a 1:1 ratio, that’s no longer a given. Other common device pixel ratios (or DPR) range from 1.5 to 2.0dpr, but it may vary. That means if someone with a 2.0dpr screen views our image, it will be half the (physical) size we expect! For every 1 css pixel, there are 2 device pixels, which means we need 4 more pixels of information in total (because height also doubles)! Definitely not optimal.
The solution seems pretty straightforward, and it is. Double the resolution. Giving the 2.0dpr screen a 60x40 version of our image will display it the same size as our 30x20 on 1.0dpr screen. Brilliant.
Now, we could just deliver the 60x40 version to both screens and let the browser resize the image on the 1.0dpr screen. But this is bad and you shouldn’t do it. Not only are we distracting the browser from better tasks, we’re dumping all that data we sent the user! Worse, it’s the sort of problem that scales.
**110x110 - 100x100 = 2100px wasted
510x510 - 500x500 = 10100px wasted
510x510 - 500x500 = 20100px wasted**
This is bad for everyone, but especially mobile users. No one wants to download a 4000x3000 hero image to discard most of it over a limited and expensive EDGE network. Determining which image asset to deliver a user gets quite complicated between server side, client side, and media query methods. But that’s a post for another time.
Resampling vs. Resizing
When changing the resolution of an image, you’re generally able to choose between resizing the image, or resampling it. For web purposes, resampling is always the better choice. The reason for this is the difference between print and digital. When an image is resized the physical dimentions change, but the number of pixels do not. Your 1000x1000px image is still 1000x1000 no matter what size you set the display to. That means for digital purposes, resizing would have no effect, just like with DPI above!
Resampling on the other hand changes the number of pixels, making its best guess based off the original image’s pixels. Since the total number of pixels is being adjusted rather than the size of each pixel, it’s relevant to digital displays. The screen is able to fill the correct number of pixel ‘slots’ with the appropriate color to display the image at an alternate size. As you might expect, resampling to a smaller size is easier than to a larger one, since cutting pixel information is more accurate than attempting to create it.
Feel free to send us a note; we'll get right back to you.