Choose useful image dimensions for high-density displays

A card displayed at 800 CSS pixels wide can use an image candidate that is 1600 image pixels wide as a 2x example. The browser may choose an appropriate source based on layout, device density and other conditions when the website provides responsive image markup. The 1600-pixel file does not mean that the card should occupy 1600 CSS pixels on the page.

Measure the actual layout before exporting. An article column, a full-width banner and a small product card rarely need the same source size. Also check the phone layout, where the image may occupy a different width or use a different crop. Making every file twice the largest desktop viewport width can waste bytes. Treat higher-density exports as candidates for a real responsive implementation rather than a single oversized file that every device must download.

This page starts with a WebP fit box of 1600 by 1600 pixels. It is an illustrative bound, so replace it with values based on the display size you measured. Fit within keeps proportions and does not enlarge a smaller source. For example, a wide original may reach 1600 pixels across while a portrait fits the height instead. Check the actual output dimensions.

If a source is only 700 pixels wide, writing a 1600-pixel export does not create the detail of a larger original. Use a better source or accept a smaller candidate. Compare Light sharpening with Off after resizing and inspect fine textures at the intended display size. For transparent graphics use PNG instead, since the current WebP export here is opaque. Keep the original design or photograph so you can create different candidates later.

The converter produces a file; your website still needs to select and present it correctly. Provide suitable source candidates, accurate size hints and reserved image dimensions in the implementation. A phone should not receive the largest image merely because it exists. Check the downloaded image in browser developer tools when evaluating the final page, because a content management system may transform it again.

View the page at ordinary and high-density screen settings, and compare detail with transfer size. A higher-resolution image is not automatically the best tradeoff for a small decorative card. Likewise, one excessively small image can look poor in a large product view. Test meaningful content such as faces and labels instead of judging only a blurred background. Keep loading priority appropriate to the image's position, and measure the real page before claiming an improvement in speed or Core Web Vitals.

Suppose your widest card is 400 CSS pixels and an illustration remains clear at that width. An 800-pixel candidate is one possible 2x export when the source supports it. Check the card at narrower layouts as well, since an image that spans the whole phone screen may have a different display width from the desktop card. Export from the original for each needed candidate rather than enlarging the smallest one. Confirm which file the browser selects in the actual page. That final selection check is what connects a local dimensions calculation to the bytes visitors really receive for the image.