Building useful websites

Website images too large or blurry? Check pixels, bytes and sizes

A small picture can still download a large file. Start with one image, record what the browser actually loads, and change the part that causes the problem.

By Coru · Published 2026-10-21 · Updated 2026-10-21

1. Name the problem before exporting another file

Choose a photograph or screenshot in a real page. Write down one failure: slow download, lost detail, or text jumping when the image arrives. These can need different repairs. This guide covers raster images in HTML image elements; CSS backgrounds and deliberately different mobile crops need separate inspection.

Keep three measurements apart: the box width on the page in CSS pixels; the chosen file’s pixel dimensions; and the downloaded bytes. A 360-pixel-wide box does not mean a 360-pixel file was downloaded. A filename containing “small” does not establish either measurement.

2. Work out a starting pixel width

Use displayed width × device pixel ratio (DPR) as a starting point for testing sharpness. For an image shown at 360 CSS pixels, DPR 1 gives 360 source pixels, DPR 2 gives 720, and DPR 3 gives 1080. Browser selection, available candidates and visual quality still matter; this calculation is not a guarantee of the exact file selected.

Suppose a workshop photo occupies a 360-pixel card but the editor uploaded a 2400 × 1600 file. Export a 720 × 480 candidate for a DPR-2 check: 2400 × 1600 is 3,840,000 pixels; 720 × 480 is 345,600. That is about 11.1 times fewer pixels, not a promised 11.1-fold reduction in file bytes or loading time.

Compare the candidate at the size readers will see, including the detail the page needs. If the original is already blurred, increasing its pixel dimensions does not recover the missing detail. Keep the source original so you can make another export.

3. A tested trap: the right CSS, the wrong sizes hint

With width-based srcset, each “w” value describes the corresponding file’s actual pixel width. The sizes attribute describes the expected display width for source selection; CSS still controls the visible layout. Check the generated HTML, even if a CMS created it.

Coru tested a local page on 21 October 2026 with three original PNG patterns, 360, 720 and 1440 pixels wide. The browser viewport was 1200 CSS pixels; CSS held the image box at 360. Each case used a fresh Chromium profile with the browser cache disabled.

With sizes="360px" and DPR 1, Chromium loaded the 360-pixel file. With the same hint and DPR 2, it loaded the 720-pixel file. With sizes="100vw" and DPR 1, it loaded the 1440-pixel file, although the visible box remained 360 pixels wide.

The last hint described the entire viewport instead of this card. Fix the hint to match the actual layout. Use 360px only for a genuinely fixed-width slot; a fluid layout needs conditions that follow its own widths and gutters. The test used Chrome 155.0.8059.12 and proves those three selections in that fixture, not every browser’s choices or a speed gain.

4. Check the delivered page in the browser

In Chrome, open DevTools → Network, turn on Disable cache, set the viewport and DPR you want to test, then reload. Filter to images. Select the request for your picture and record its URL and transferred size. A result served from memory or disk cache is not a fresh-download byte measurement.

In Elements, select the image and check its rendered box, srcset and sizes. Match the Network request to the actual chosen file, rather than assuming the src fallback was used. Inspect that file’s pixel dimensions separately. Repeat at a wider viewport and a different DPR after a fresh reload.

Keep the same browser, viewport, DPR, cache setting and network conditions when comparing before and after. If an image service or service worker serves a different variant, record that too. A smaller download is useful evidence about that image; it does not by itself establish a faster whole page.

5. Choose the repair that matches your observation

Oversized chosen file: check srcset candidates and sizes against the rendered slot before compressing the original again.
Appropriate dimensions, too many bytes: compare an alternative export or format at the same dimensions and useful visual quality. Measure the delivered file; there is no universal KB target for every photo or screenshot.
Visible blur: compare the chosen file with the width × DPR estimate, then inspect source quality and compression. A phone can need more pixels than a wider desktop card.
Text moves as the image loads: provide correct width and height attributes to reserve its aspect ratio, with responsive CSS such as max-width: 100% and height: auto. Reserving the ratio does not require a fixed-size layout.
Important opening image appears late: check that it is not lazy-loaded. Lazy loading is useful for images farther down the page; it does not shrink their files.

6. Copy this one-image diagnostic card

Page and image purpose: ___. The specific failure I can see: ___.
Test conditions: browser/version ___; viewport ___; DPR ___; cache ___; connection ___.
Rendered width ___ CSS px × DPR ___ = starting width ___ source px.
Chosen file URL ___; actual pixel dimensions ___; transferred bytes ___; srcset/sizes ___.
One change ___; after reloading, chosen file ___ and bytes ___.
Quality at intended viewing size ___; layout stable ___; remaining problem ___.

A stopping point you can verify

Keep the change when the intended detail is readable, the chosen file fits the tested display needs, and the original failure has improved without a new one. Check the same image in its other page locations before replacing a shared asset. Preserve a baseline if you want to compare later.

If this check leaves you stuck, use the feedback form with the page URL, viewport, DPR and observed symptom. That is more actionable than “images are slow”. Do not send private page addresses or account details.