{"id":15777,"date":"2026-11-14T07:50:00","date_gmt":"2026-11-14T06:50:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=15777"},"modified":"2026-10-26T12:18:52","modified_gmt":"2026-10-26T11:18:52","slug":"which-image-format-a-browser-receives-checking-format-selection-and-cache-rules","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/tutorials-en-web-development\/which-image-format-a-browser-receives-checking-format-selection-and-cache-rules\/","title":{"rendered":"Which Image Format a Browser Receives: Checking Format Selection and Cache Rules"},"content":{"rendered":"

A server can return different image formats at the same URL. The request header Accept<\/code> expresses media-type preferences; the response header Vary<\/code> helps caches select a suitable stored response. These are related mechanisms, but neither a different content type nor a missing header proves that visitors received a broken image.<\/p>\n

A historical check of twenty front pages on 6 September 2026 recorded 1,345 image entries and sampled 76 image URLs. The saved results remain useful, but the original interpretation overstated the method: the implementation compared a GET request with a HEAD request, not two otherwise identical GET requests. GET requests the response body as well as headers; HEAD requests the headers without the body. The findings below distinguish recorded values from conclusions that require a new controlled test.<\/p>\n

\"Historical
Saved results from 6 September 2026; method differences prevent an isolated Accept-based conclusion.<\/figcaption><\/figure>\n

What the historical sample actually recorded<\/h2>\n

Fourteen of the 76 pairs had different declared media types. Six New York Times samples reported WebP versus JPEG with Vary: Accept<\/code>. Six Zeit samples reported WebP versus JPEG without a recorded Vary value; two Onet samples reported AVIF versus PNG without one. The remaining 62 pairs had the same declared media type. This does not establish identical file contents.<\/p>\n

The requests differed in method as well as Accept. The alternative request also used Accept: image\/*<\/code>, which permits AVIF and WebP rather than modelling a browser without those formats. Consequently, the fourteen differences are leads for a follow-up test, not fourteen proven cases of Accept-based negotiation. The saved data contains summaries, not both response bodies and complete raw headers.<\/p>\n

How a more useful comparison works<\/h2>\n

A controlled comparison uses GET for both requests, the same URL and matching options apart from Accept. A baseline request can explicitly exclude AVIF and WebP with q=0<\/code>; a preference such as image\/*<\/code> does not exclude either format. Accept still expresses a request preference: the actual response needs checking.<\/p>\n

Useful evidence includes the final URL, status, declared media type, actual file format, byte count, body hash and complete response headers. Equal type and length do not prove equal bytes. Different bytes can also reflect a changing image, CDN behaviour or request timing. Repeated comparisons and, where available, server configuration provide stronger evidence about the cause.<\/p>\n

Vary controls reuse, not permission to store<\/h2>\n

When a cacheable response is selected according to Accept, Vary: Accept<\/code> normally communicates that selection criterion. A cache cannot simply reuse that stored response for a request with a non-matching Accept value. HTTP permits normalization when comparing field values; storing a separate copy for every literal spelling is not an unavoidable rule.<\/p>\n

Whether storage and reuse are allowed also depends on cache controls, freshness and the cache configuration. Missing Vary can create an incorrect-reuse risk, but the historical sample did not demonstrate a faulty CDN response. Restrictions such as no-store<\/code> and a deliberately configured cache key change the assessment. Vary: *<\/code> prevents direct reuse without validation.<\/p>\n

The header needs token-based parsing. Vary: Accept-Encoding<\/code> concerns content encoding and is not equivalent to Vary: Accept<\/code>. An implementation that merely searches for the substring accept<\/code> can confuse the two.<\/p>\n

A verified lesson from the checker<\/h2>\n

An older local implementation passed the requested header in an option named accept<\/code>. The shared request library expects kopfzeilen<\/code>. Comparing those source files verifies the interface mismatch; the intended header was not passed through that option. A test therefore needs to inspect the outgoing request as well as the simulated response. Identical responses alone do not rule out negotiation.<\/p>\n

Dimensions, loading and alternative text<\/h2>\n

The saved markup analysis counted 783 of 1,345 image entries with at least one missing or invalid numeric dimension. This is not a count of images missing both width and height. Six sampled pages had valid dimensions for every detected image. On Heise, 423 of 426 entries lacked a complete valid pair.<\/p>\n

Correct width<\/code> and height<\/code> help reserve the aspect ratio before an image loads. CSS can also reserve suitable space. Missing attributes therefore identify a review point, not a measured layout shift. Cumulative Layout Shift measures how much visible content unexpectedly moves on the page. Measuring it requires observing the rendered page.<\/p>\n

The figure 762 is another heuristic: these entries appeared after the first three images in source order and did not carry loading=\"lazy\"<\/code>. No viewport or CSS layout was measured. Source order cannot determine visibility, and an important initial-view image should not be delayed merely because it is the fourth image in HTML.<\/p>\n

Twenty-seven entries lacked an alt attribute. Empty alt=\"\"<\/code> can be appropriate for purely decorative images or images whose information is already provided nearby. Whether that choice is appropriate depends on the image’s purpose; informative and functional images need a suitable accessible alternative.<\/p>\n

What was outside the sample<\/h2>\n

The checker selected at most six distinct image URLs per page from detected markup. This did not cover every CSS background, script-created image or responsive candidate actually chosen by a browser. Six samples do not establish the behaviour of an entire delivery service.<\/p>\n

Three records contained no detected images: Stack Overflow returned 429, Allegro returned 403, and the recorded Bund response yielded no image entries. These cases do not prove that those pages normally contain no images or that two rely on JavaScript. A refused or rate-limited request describes that attempted access, not a complete browser visit.<\/p>\n

A bounded comparison for one URL<\/h2>\n

The following Bash example uses curl 8.4 or later, file<\/code> and GNU coreutils. The example URL is a placeholder. Both requests are GETs, redirects remain HTTPS, and each download is limited to 10 MiB and 30 seconds. Output remains in a newly created temporary directory for inspection.<\/p>\n

Shell<\/span>