HDR and Wide-Gamut Images on the Web: A 2026 Field Guide

HDR images have been "coming to the web" for so long that most engineering teams stopped listening, and fair enough: for years the honest advice was to wait. That advice is now stale. Two things happened between late 2023 and late 2025 that quietly ended the waiting period, and most image pipelines haven't noticed yet.

First, the format war didn't happen. Adobe's 2023 gain map specification was adopted by Google as Ultra HDR on Android 14, by Apple as Adaptive HDR on iOS 18, and was then formally published as ISO 21496-1:2025. One standard, every major platform. Second, the last big rendering holdout fell: Safari 26.0 shipped HDR image support in web content in September 2025 (WebKit blog, 2025). 2026 is the first year HDR stills are practically deliverable at production scale. This guide covers what that means and how to ship it.

TL;DR >- Adobe's 2023 gain map spec became ISO 21496-1:2025, unifying Google's Ultra HDR and Apple's Adaptive HDR under one standard.- Safari 26.0 (September 2025) added HDR image rendering plus the dynamic-range-limit CSS property; Safari had HDR video since 2020 but never HDR images until now (WebKit, 2025).- One practitioner matrix estimates ~95% of in-use browsers render gain-map HDR on capable displays; Firefox is the holdout (Greg Benz, 2025).- Wide gamut is not HDR: P3 is more chromaticity at SDR luminance, HDR is luminance headroom. Only ~1 in 80 web images carries a wide-gamut ICC profile today (Web Almanac, 2024).- Practical gain-map overhead runs roughly 10-30% depending on settings. Budget it like any other rendition decision, and gate delivery with @media (dynamic-range: high).

Why is 2026 the first year HDR images are practical?

Because the standard and the last major renderer arrived within months of each other. ISO formally published 21496-1, the gain map metadata standard, in 2025 (ISO, 2025), and Safari 26.0 shipped HDR image support that September (WebKit, 2025). Before those two events, HDR stills meant fragmented formats rendering inconsistently in a minority of browsers.

The convergence story is worth spelling out, because it's rare. Adobe published its gain map specification in 2023. Chrome 116 shipped default-on rendering of JPEG gain maps in August 2023. Google built the same approach into Android 14 as Ultra HDR: a standard JPEG with an embedded 8-bit compressed gain map, fully backward compatible with every existing decoder (Android Developers). Apple adopted the approach as Adaptive HDR in iOS 18. ISO then formalized it as 21496-1:2025. Four ecosystems, one spec, no war.

From Adobe's 2023 spec to ISO 21496-1:2025 and Safari 26, every major platform converged on one gain-map standard (ISO; WebKit, 2025).

Safari was the missing renderer, and its absence mattered more than market-share numbers suggest, because Apple hardware is where capable displays concentrate. Safari had supported HDR video since version 14 in 2020, but images waited another five years (WebKit, 2025). With Safari 26, one practitioner-maintained support matrix estimates roughly 95% of browsers in use will render gain-map HDR (JPEG and AVIF) when paired with an HDR display (Greg Benz, 2025). The remaining holdout is Firefox, which we'll get to.

Meanwhile phone cameras have been capturing HDR by default for years. The pipeline gap is no longer capture or rendering. It's delivery: almost nobody's image infrastructure produces HDR renditions.

Wide gamut is not HDR

They solve different problems on different axes. Wide gamut (Display P3, Rec.2020) is about chromaticity: more saturated colors at standard luminance. HDR is about luminance: highlight headroom above SDR white. A P3 image is not an HDR image, and conflating them produces pipelines that ship neither correctly.

The confusion is understandable because capable hardware overlaps. But the encoding requirements differ. A wide-gamut SDR image needs its color space signaled, via an ICC profile or, far more compactly, CICP metadata, which does the job in 4 bytes versus kilobytes of ICC payload, a difference the Web Almanac specifically flags as material at CDN scale (Web Almanac, 2024). An HDR image additionally needs a way to represent luminance beyond SDR white: 10- or 12-bit AVIF with a PQ or HLG transfer function, or an SDR base image plus a gain map.

The web is further behind on both axes than most teams assume. Only about 1 in 80 web images carries a wide-gamut ICC profile, roughly 1 in 10 of the images that carry any ICC profile at all, though Display P3 usage is ticking up around 10% in relative terms year over year (Web Almanac, 2024). Nearly the entire web ships sRGB while nearly every premium device can display more.

Only about 1 in 80 web images carries a wide-gamut ICC profile, roughly 1 in 10 of images carrying any ICC profile (Web Almanac, 2024).

On the hardware side, resist the urge to quote a display-penetration percentage; no rigorous public figure exists. The defensible framing is device capability: Apple has shipped P3 displays on iPhones and Macs since around 2016, and flagship Android followed from roughly 2017. Better still, don't estimate at all. Detect at runtime with @media (color-gamut: p3) and @media (dynamic-range: high) and let each visitor's actual hardware answer the question.

What is a gain map, and why did it win?

A gain map is a second, small image embedded alongside a normal SDR image, encoding per-region brightness multipliers that reconstruct the HDR version on capable displays. Structurally it's a quarter-to-full-resolution single-channel JPEG-compressed image plus metadata, standardized as ISO 21496-1:2025. On any non-HDR display, the file is just a normal image.

That last property is why gain maps won for photographic delivery. The fallback isn't a separate file you manage; it's the base image itself, tone-mapped once by a human or a capture pipeline that saw the actual scene, rather than tone-mapped on the fly by whatever browser or OS the viewer happens to run. Native HDR AVIF (10/12-bit, PQ or HLG, Rec.2020 or P3 primaries) is the purer encoding, but on SDR screens its rendering depends on the viewer's tone mapper, which is exactly the kind of uncontrolled variable brand and photography teams hate.

Ultra HDR on Android 14 demonstrates the compatibility argument at OS scale: a standard JPEG with an embedded 8-bit compressed gain map that every legacy decoder reads as a plain JPEG (Android Developers). Nothing breaks, anywhere, ever. The HDR is progressive enhancement in the literal sense.

The overhead question is active research, not a settled constant. An ICCV 2025 paper, Gain-MLP, replaces the stored gain-map image with a lightweight MLP of roughly 10 KB (ICCV 2025, Canham et al.). Learned representations compressing perceptual deltas is familiar territory; it's the same trajectory we mapped in neural compression vs traditional codecs.

Which browsers support what in mid-2026?

Chromium renders JPEG gain maps by default, Safari 26 renders HDR images with CSS control, and Firefox renders none of it. That asymmetry, not encoding difficulty, is what dictates delivery strategy: you need a decision tree, not a single output format. Here's the matrix as it stands in mid-2026.

Two caveats keep this from being a solved problem. Firefox has no HDR image support and no committed timeline, only open community requests on Mozilla Connect and Bugzilla. And interop has rough edges: early Apple ISO gain-map rendering diverged from Chrome's, with headroom treated differently by roughly three stops in reported cases (Greg Benz Photography, 2025-26). Visual QA across engines is still mandatory; the standard's existence doesn't guarantee identical rendering.

The practical reading of the matrix: JPEG gain map is the broadest HDR carrier today, AVIF is the efficiency play with 93.4% baseline support (caniuse, 2026), and every strategy needs a genuine SDR floor for Firefox and SDR displays.

AVIF HDR, gain-map JPEG, or SDR: how do you decide?

Serve gain-map images as your HDR carrier, let capable displays reconstruct HDR, and let everything else render the SDR base; use media queries to gate any HDR-only styling or sources. The decision tree is short because the gain map's built-in fallback does most of the work for you.

In pipeline terms:

1. HDR-capable display and gain-map-capable browser (Chromium, Safari 26+): serve the gain-map rendition. JPEG gain map has the widest default-on support; AVIF gain map adds compression efficiency where enabled.
2. Wide-gamut but SDR, or Firefox: the same file's SDR base renders correctly. Encode the base in P3 with CICP where your audience skews to capable devices, since CICP signals color space in 4 bytes versus multi-kilobyte ICC profiles (Web Almanac, 2024).
3. Legacy everything: the SDR base is still just a valid image. No negotiation failure mode exists.

Gate on capability, not user-agent sniffing:

```css
.hero { background-image: url(photo-sdr.jpg); }

@media (dynamic-range: high) {
.hero { background-image: url(photo-gainmap.jpg); }
}
```

For content images, <picture> with type-based selection handles the AVIF/JPEG split while the gain map handles the HDR/SDR split within each file. In JavaScript, matchMedia('(dynamic-range: high)') drives the same logic for canvas and dynamically loaded imagery.

One genuinely new problem: mixed SDR/SDR-plus-HDR pages. An HDR hero at full headroom next to SDR UI chrome makes the interface look dim and the image look like it's glowing through the page. Safari 26's dynamic-range-limit CSS property exists precisely to constrain that bloom (WebKit, 2025). Use it deliberately; unconstrained HDR in a shopping grid is a design bug, not a feature.

The byte cost of HDR, and how to QA it

Budget roughly 10-30% overhead for a gain-map rendition versus its SDR-only equivalent, varying with gain-map resolution and compression settings; no standardized fixed percentage exists. The second image channel is small and single-channel, so the cost is a rendition decision like any other, not a doubling.

Whether that 10-30% is worth it is the wrong question asked in the usual way. Bytes are a means; what you're buying is measurably higher perceived fidelity on the devices your highest-value visitors carry. We've argued the general form of this position in why file size is the wrong metric. Spend the overhead where luminance headroom changes the image (jewelry, sunsets, automotive paint, food) and skip it where it doesn't (flat product-on-white, iconography, UI screenshots).

The harder problem, and the one nobody in the HDR content wave is addressing, is QA at scale. Every quality metric your pipeline currently trusts was built for SDR. PSNR and SSIM assume a shared luminance range between reference and rendition; compare an HDR reconstruction against an SDR reference and the arithmetic runs but means nothing, the failure mode we dissected in PSNR vs SSIM vs "looks good to humans". And a gain-map file is two images plus metadata: base, map, and headroom parameters can each independently be wrong while the other components verify clean. The documented ~3-stop Chrome/Apple rendering divergence means even a correct file can't be assumed to look correct everywhere.

An HDR QA loop therefore needs three checks per asset: the SDR base validated on its own (it's what most of the world sees), the reconstructed HDR validated against the HDR master under a perceptual model that understands luminance headroom, and rendering sampled across the actual engine matrix rather than one reference viewer. At Inverity this is the pipeline question we find most interesting right now, because it's measurement the way humans see it extended to a luminance axis the standard metrics never modeled. Teams that ship HDR without an HDR-aware measurement loop aren't optimizing; they're guessing with more dynamic range.

FAQ

Do browsers support HDR images in 2026, and what about Firefox?

Mostly yes. Chromium browsers have rendered JPEG gain maps by default since Chrome 116 in August 2023, and Safari 26.0 added HDR image support in September 2025 (WebKit, 2025). One practitioner matrix estimates ~95% of in-use browsers render gain-map HDR on capable displays (Greg Benz, 2025). Firefox supports none of it yet; requests remain open.

What is a gain map, and how is it different from a normal HDR file?

A gain map is a small secondary image embedded in a standard SDR file, encoding brightness multipliers that reconstruct HDR on capable displays, standardized as ISO 21496-1:2025. A native HDR file (10/12-bit AVIF with PQ/HLG) encodes HDR directly but leaves SDR fallback to the viewer's tone mapper. Gain maps carry their own author-controlled fallback.

Should I use AVIF HDR or JPEG with a gain map?

For broadest HDR reach today, JPEG gain map: it renders in HDR by default in Chromium and Safari 26, and degrades to a plain JPEG everywhere else (Greg Benz, 2025). AVIF is the stronger compressor with 93.4% baseline support (caniuse, 2026), but AVIF gain maps sit behind a flag in Chromium. Many pipelines ship both via <picture>.

How much larger are HDR gain-map images, and is the payload worth it?

Practical overhead commonly runs about 10-30% over the SDR-only equivalent, depending on gain-map resolution and compression; there's no fixed standard percentage. It's worth it selectively: imagery where highlight headroom is the product (metal, glass, skies, screens) justifies the bytes. Research is shrinking the cost further, with ICCV 2025's Gain-MLP replacing the map with a ~10 KB network (Canham et al., 2025).

What happens to an HDR image on an SDR screen, and do I need separate fallbacks?

With a gain map, nothing breaks and no separate fallback is needed: the browser simply displays the embedded SDR base image, which the author tone-mapped deliberately (Android Developers). Native HDR AVIF is riskier on SDR screens because tone mapping happens in the viewer, with results varying by engine. That built-in graceful degradation is the main reason gain maps are winning photographic delivery.