Why is my product photo sharp on one screen but soft on another?

Keep the product and rendering conditions fixed

Start with one approved photo, the same variant and the same gallery view. Record browser zoom before comparing screens. Ask your theme maintainer for the rendered width in CSS pixels and the current devicePixelRatio. MDN describes this ratio as physical pixels relative to CSS pixels, and notes that page zoom can change it.

Do not compare a small thumbnail on one screen with an enlarged viewer on another. That changes the task and required detail. Keep the display slot, selected asset identity and intended inspection distance explicit in the report.

Calculate an inspection target

This fictional bottle image occupies a 480-CSS-pixel slot. At a measured density of 2, a rough one-image-pixel-per-display-pixel budget is 480 × 2 = 960 pixels across. If the loaded rendition is only 480 pixels across, the mismatch deserves inspection. This arithmetic is an estimate for that condition, not a promise of visible improvement or a universal export minimum.

Measure the image’s actual rendered width, not a larger container that includes padding. The simple width × density estimate assumes that image content fills that width without an additional transform; art-directed crops or magnified viewer content need their own inspection. Record the viewing mode rather than reuse a thumbnail budget for an enlarged crop.

Check what was delivered before regenerating

Have the maintainer inspect the actual selected source, its file dimensions and the theme’s size hints. Compare that rendition with the approved master at the intended display size. If the master contains the detail but the store requests a smaller file, repair delivery. If the master lacks it, obtain better reference photography or a reviewed replacement.

Do not infer original file dimensions from a browser value without checking its meaning. Request the selected file’s verified dimensions. Compression, sharpening and fabricated lettering can also affect appearance; keep them fixed when testing density.

MDN distinguishes page zoom, which can change devicePixelRatio, from pinch zoom, which does not change it in the same way. Keep the actual zoom mode and display recorded. currentSrc identifies a selected URL, not verified encoded dimensions or successful loading; inspect the delivered file separately before concluding the store selected too few pixels.

Choose a bounded asset budget

Set an approved rendition ladder for the actual gallery and enlargement uses, then compare visual detail and loading cost on representative screens. Stop increasing the budget when the relevant product detail is adequately shown; an oversized file is not automatically a better shopping experience.

Use the source pixel budget worksheet as a manual review record. Sample rows are fictional. It does not connect to, import into or modify an external store or production machine.

CartVisual’s available output options can supply candidate assets for review. This manual budget neither guarantees the returned file dimensions nor changes an external theme. Record measured slot width, density, selected file and the observed detail separately.

The CSV has two fictional 360-CSS-pixel examples: density 2 gives a 720-pixel target versus a 600-pixel source, while density 3 gives 1080 versus 1200. Its can_supply_nominal_samples “yes” is arithmetic only, not approval of label detail, compression, accuracy or loading cost. Add your measured case and leave review_status pending until the visual check. For wrong merchandise use identity mapping; for moving layout use slot stability.