skip to content

A design team asks for 3x image assets so photos look sharp on high-density phone screens. How would you decide how far up the density ladder to go, and what does compression quality have to do with the answer?

level: middleimportance: should knowfreq 38%

answer

  1. density cost is squared, not linear
  2. 2x to 3x is 2.25 times the pixels
  3. perceptual returns flatten after 2x
  4. artifacts hide below one CSS pixel
  5. cap the density you honour

basics

~20 s

Going from 2x to 3x costs about 2.25 times the pixels for a perceptual gain most people cannot see, so most teams cap at 2x. The lever that matters more is compressing high-density variants harder, since their artifacts fall below one CSS pixel.

solid answer

~60 s

Density is an area cost, not a linear one: a 3x asset carries 2.25 times the pixels of a 2x asset of the same layout size, and roughly that much more weight. The perceptual return past 2x is small — at typical phone viewing distances the extra detail is at or beyond what the eye resolves — so I would push back and cap the commitment at 2x unless there is a specific case like fine text rendered into an image or a zoomable product shot. The more useful lever is quality: because a 2x image's compression artifacts land below the size of one CSS pixel, you can compress it noticeably harder than a 1x asset and still have it look cleaner, which claws back much of the density cost. I would also note that a width ladder already covers density — the browser factors the screen's pixel ratio into its choice — so "3x assets" usually means "raise the ceiling of the ladder," not "add a parallel set of files."

code

javascript · 14 lines
javascript
const layoutWidth = 400;      // CSS px the image occupies
const quality = { 1: 80, 2: 62, 3: 55 }; // higher density tolerates lower quality

for (const density of [1, 2, 3]) {
  const px = layoutWidth * density;
  console.log(
    `${density}x -> ${px}px wide, ` +
    `${(density ** 2).toFixed(2)}x the pixel count of 1x, ` +
    `encode at quality ${quality[density]}`
  );
}
// 1x -> 400px wide, 1.00x the pixel count of 1x, encode at quality 80
// 2x -> 800px wide, 4.00x the pixel count of 1x, encode at quality 62
// 3x -> 1200px wide, 9.00x the pixel count of 1x, encode at quality 55

go deeper

for a junior

Know that high-density screens pack more physical pixels into each CSS pixel, so a crisp image needs more pixels than its layout size, and that this multiplies file size quickly.

for a middle

Be ready to do the arithmetic aloud: 3x is 2.25 times the pixels of 2x because the cost is area-based, and explain why high-density variants can be encoded at a lower quality setting.

for a senior

Demonstrate that you would settle this with a blind comparison on target hardware rather than an opinion, and that you would raise a density ceiling only for the image classes where the extra detail is genuinely visible.

for a principal

Own the declared density commitment as policy — one number the whole organisation designs and budgets against — and be able to defend it against both design pressure upward and byte pressure downward.

## Density is squared, like every other image cost Device pixel ratio is the number of physical screen pixels per CSS pixel. A phone reporting a ratio of 2 needs 800 image pixels of width to render an image crisply in a 400 CSS-px slot; a ratio of 3 needs 1200. Because image data is two-dimensional, the jump from 2x to 3x is not a 50% cost increase — it is (3/2) squared, or 2.25 times the pixel count, and in practice something close to twice the bytes after compression. That is the number to put in front of the person asking. Not "3x is bigger," but "3x roughly doubles the weight of every photo on the page relative to 2x." ## What the eye actually gets back The perceptual return curve is steep from 1x to 2x and shallow after. At a typical phone viewing distance the difference between 1x and 2x is obvious to almost everyone — 1x on a high-density screen looks soft and slightly blurred. The difference between 2x and 3x on photographic content is subtle at best and, for most viewers and most images, not reliably identifiable in a side-by-side test. This is why the common industry position settled on a 2x commitment for photographs. There are genuine exceptions, and a good answer names them rather than pretending density never matters above 2x: - **Images containing fine text or thin line art.** Sharp high-contrast edges are exactly where extra resolution remains visible, which is also why such content is usually better served as vector art than as a raster at any density. - **Zoomable images**, such as a product detail view where the user pinches in. There the "layout size" is not the initial layout size, and the ceiling has to account for the zoomed state. - **Screenshots of user interfaces**, which are effectively images of text. For the ordinary hero photograph or card thumbnail, 2x is the honest ceiling. ## Quality is the lever people forget The most useful thing to bring to this conversation is that density and compression quality trade against each other, and the trade runs in your favour. When an image is displayed at half its intrinsic size — which is exactly what a 2x asset is — each pair of image pixels is squeezed into one CSS pixel. Compression artifacts, ringing around edges, and blocking all shrink correspondingly, landing below the size the eye can pick out at that display size. The practical consequence is that a 2x variant can be encoded at a distinctly lower quality setting than a 1x variant and still look cleaner overall, because the downscaling averages the noise away. So the pipeline rule is: high-density variants get a lower quality setting than low-density ones. This recovers a large part of the extra weight that density costs, and it is the reason a 2x asset in practice is often nowhere near four times the bytes of the 1x. If someone is generating every rung at the same fixed quality, that is the first thing to change — before arguing about whether 3x is warranted. ## "3x assets" is usually the wrong shape of request There is a framing issue worth correcting too. If images are already delivered as a ladder of widths, density is not a separate axis. The browser knows the screen's pixel ratio and knows how wide the image will be laid out, and it chooses a candidate width accordingly — a 3x phone in a 400 CSS-px slot simply asks for a candidate near 1200px wide. Adding a parallel "3x set" of files on top of that duplicates what the ladder already expresses. What the design team is really asking for is that the ladder's ceiling be raised: does the top rung go to layout width times 2, or times 3? That reframing usually resolves the argument quickly, because it turns a vague quality request into one number with a measurable byte cost attached. ## How to decide, concretely Run the comparison rather than debating it. Take the two or three most important images on the site, produce a 2x variant at your reduced quality setting and a 3x variant, and compare both the file sizes and a blind side-by-side on the actual target hardware. In most cases the 3x file is roughly twice the size and no one can pick it out. If someone can, and the image class matters commercially, raise the ceiling for that class only — density ceilings do not have to be uniform across every image role. Finally, cap the density you honour rather than following whatever the device reports. Some devices report ratios above 3, and serving them proportionally means enormous files for screens whose extra pixels are far past the point of perceptual return. A declared ceiling — "we serve up to 2x" — is a strategy; following `devicePixelRatio` without a cap is an open-ended byte commitment.

  • Where does the argument for high density genuinely hold up?
    Content with fine, high-contrast edges — text baked into an image, thin line art, UI screenshots — where extra resolution stays visible past 2x. Zoomable product images are the other real case, because the effective layout size is the zoomed size, not the initial one. For ordinary photographs the return past 2x is not reliably perceptible, so those two classes are worth a higher ceiling and the rest are not.
  • Should you read the device's reported pixel ratio and serve proportionally?
    No — treat it as an input, not an instruction. Some devices report ratios of 3 or more, and honouring that literally is an open-ended byte commitment for pixels past the point of perceptual return. Declare a ceiling you are willing to serve, typically 2x, and let devices above it receive the top rung. A stated cap is a strategy; following the reported ratio is not.
  • Why can a 2x variant be compressed harder than a 1x variant of the same image?
    Because it is displayed at half its intrinsic size, so every two image pixels are averaged into one CSS pixel. Compression artifacts, ringing and blocking shrink with that downscale until they fall below what the eye resolves at the display size. The net effect is that a lower quality setting on a high-density variant still looks cleaner than a higher setting on the 1x, which recovers much of density's cost.

saying these in an interview costs you the question

  • Treats 3x as only 50% more data than 2x
  • Encodes every density variant at the same quality setting
  • Serves proportionally to whatever pixel ratio the device reports
  • Adds a parallel density set on top of an existing width ladder
  • Claims density never matters above 1x on any content

context

resolving links…