Which image does a phone actually download?

A small image slot does not make the downloaded file smaller. If every visitor receives the same full-size photo, a phone can still fetch pixels the layout does not use. Compression and responsive selection solve different parts of that problem.

Our website workflow explains preparation, while the image-delivery guide connects it to performance diagnostics. This experiment follows one photo from prepared files to a browser’s actual selection, without treating a score as the result.

We made proportional copies in an external image editor before compression; Bitinz did not resize them. On 2026-10-29 each copy was processed at Balanced in the local engine. Its recorded dimensions, bytes and checksum identify the candidate used in the browser experiment.

The local page offered candidates through srcset with a matching sizes rule. Browser observations record viewport width, pixel density and the selected resource. They measure image payload, not a complete page load or a simulated mobile network. Our editorial policy describes the evidence.

Compare the candidate sizes here, then check the browser-selection record linked in the sources. The browser can only choose among files that the page actually offers.

Bitinz · 1 KB = 1000 bytes.

Each row used a fresh browser context with caching disabled. The widest high-density case selected the largest candidate because the offered set had a large gap at that point. An intermediate candidate would be worth testing; the browser can only select a file that exists in the list.

Source photograph detail

Compressed photograph detail

Inspect the displayed photo on a small screen and a high-density display. The smallest candidate is not automatically the best choice if it leaves the image visibly soft. Likewise, a large candidate is not justified merely because its compressed size looks impressive.

The browser-selection record is a snapshot of the stated environment. Cached resources and browser decisions can affect later visits. To repeat the observation, use a fresh browser context and inspect the requested image rather than inferring it from the visible dimensions.

Use the image compressor on the prepared copies, then let your site or content-management system offer appropriate variants. If its generated markup points every screen to one large file, compression alone does not change that decision.

Keep sizes aligned with the CSS layout. A browser uses that hint together with the available candidates and display density; it cannot read the author’s intention from a filename. Check the selected resource after changing the layout.

For a repeated workflow, the developer API can compress prepared files as part of publishing. Resizing remains a separate preparation step. Our quality guide explains how to compare details before replacing an image.

1. 01Measure the image slot and decide which proportional widths the design needs.
2. 02Prepare and compress those copies while retaining the editable original.
3. 03Offer the candidates with a sizes rule that matches the layout.
4. 04Inspect the selected resource and the visible photo on different displays.