How Large Should a Retina Image Be? CSS Pixels Versus File Pixels

CSS pixels are layout units. Image pixels are samples stored in the file. A high-density display can use multiple device pixels to draw one CSS pixel, which is why a photograph shown at 400 CSS pixels may benefit from an 800-pixel-wide source on a 2x display. Device pixel ratio and browser zoom influence the relationship. The practical first measurement is the image's rendered box, not the monitor's marketing resolution. A sidebar portrait on a large monitor can still occupy only a small number of CSS pixels.

Use a concrete example: an original portrait is 2400 by 3000 pixels, while the design displays it at 320 by 400 CSS pixels. A 1x export is 320 by 400; a 2x export is 640 by 800. Both preserve the original aspect ratio. A 640-pixel file displayed at 640 CSS pixels is not magically a 2x image because its filename contains @2x. The display dimensions must be half the file dimensions for that relationship. Establish file naming and layout rules together so developers and designers mean the same thing.

A 400 by 300 image contains 120,000 pixels. Its 800 by 600 counterpart contains 480,000 pixels. That fourfold increase affects decoding memory and processing even when compression keeps the transfer size relatively small. A simple four-channel bitmap uses roughly four bytes per pixel before additional buffers and browser overhead. A 4000 by 3000 image therefore represents about 48 million bytes for one decoded buffer. A tiny WebP download can still decode into a large bitmap; compressed file size does not describe the full memory cost.

This arithmetic explains why a universal 3x export is not a harmless quality setting. Tripling both edges creates nine times the original pixel count. Some detailed photography benefits from higher-density candidates, while a softly blurred decorative background may not. Textured products and hair can reveal differences that flat shapes do not. Compare at the real displayed size on representative devices. If a larger candidate produces no meaningful improvement for the intended task, keep the smaller one. File-size budgets are design constraints, not proof that every image must reach an identical number of kilobytes.

Use the image resizer to enter the needed width and let height follow automatically. Start every size from the original rather than deriving a 2x candidate from an already-downscaled 1x file. If your only source is 320 pixels wide, exporting it at 640 pixels adds samples but cannot recover original texture. You may prefer the result aesthetically, but it is not equivalent to a real 640-pixel capture. The upscaling guide explains the distinction and the limits of interpolation.

For vector artwork, render at the required pixel dimensions directly from the vector master. A 24 CSS-pixel icon can have a 48-pixel PNG export for a 2x context, generated with SVG to PNG. Where the destination supports SVG safely, keeping the vector can avoid a raster-size family altogether. Tiny artwork still needs visual inspection: a complex logo may be illegible at 24 pixels regardless of file resolution. Optical simplification is a design task, and a larger source cannot make microscopic lettering readable at the same displayed size.

A fixed 40 CSS-pixel avatar can offer a 40-pixel source at 1x and an 80-pixel source at 2x. A fluid article image generally needs width descriptors and a sizes attribute describing its changing layout slot. The responsive image guide covers that choice. Do not force every mobile visitor to download the largest file because some phones have high-density screens. Offer useful candidates and let the browser choose. Its selection considers more than your desktop window width, so verify actual requests rather than guessing.

Reserve the aspect ratio before the image loads, and keep all resolution-switching candidates in the same composition. If a card requires a portrait crop on mobile and a landscape crop on desktop, treat that as art direction rather than merely a density difference. A high-resolution file with the wrong crop may be sharper but less informative. Use width and height attributes with responsive CSS, then check that borders and padding have not accidentally reduced the available slot. Those small layout differences can explain unexpected resampling and a soft edge around otherwise correctly sized artwork.

For a screenshot, inspect the smallest text at its final displayed size. Downscaling can improve fit but also merge one-pixel strokes or make interface labels too small. Keeping a 2x source can help a high-density screen, but a wide screenshot squeezed into a narrow column may still require a cropped detail or zoom link. The screenshot optimization guide covers that trade. Avoid heavy sharpening to compensate for an image that is physically displayed too small to read; the solution may be a different composition or real HTML text.

DPI metadata is relevant when converting pixels to physical print dimensions, not when adding detail to a browser image. Changing 72 DPI to 300 DPI while retaining the same width and height does not create more screen samples. Confirm dimensions, output format, transfer weight, and the selected resource after publishing. Compare both a fresh uncached load and a returning visit. A successful high-density workflow preserves visible detail where readers need it while avoiding giant decorative downloads. Record the intended CSS slot alongside the export so the next person does not unknowingly display a 2x asset at full pixel width.