Why HDR Photos Look Flat When You Share Them (and How Gain Maps Fix It)

The short answer

That distinction matters because the fixes are different. If the map is still in the file, the fix is to view it somewhere that renders HDR. If the map was stripped by an edit or an upload pipeline, you need a copy that keeps it. And if the source was never HDR to begin with, no viewer will make it glow; the only honest option is to generate a plausible map, and to know that is what you did.

What a gain map actually is

A gain map is a low-resolution brightness multiplier stored next to a normal image, and it is how one file can look correct on both an SDR screen and an HDR one. Android's Ultra HDR specification describes it as "a logarithmic map indicating how much to brighten each pixel in the SDR rendition to produce the target HDR rendition," and recommends storing it at a quarter of the primary image's resolution per dimension, so a 1920 by 1080 photo carries a 480 by 270 map (Android Ultra HDR Image Format v1.1).

An HDR-aware display reads the base image, reads the map, and multiplies one by the other. Because the map is keyed to the display's own capability, a phone that can push highlights three times brighter than white applies more of the map than a laptop that can push them one and a half times. Anything that does not understand the map, which was every viewer in the world until 2023, simply shows the base image. The specification calls this out as the design goal: no clipping, no crushed shadows, no local contrast changes in the fallback. It is a clean degrade, not a broken one.

Three names describe the same idea, and the naming is where most confusion starts:

• Ultra HDR is Google's name. It shipped with Android 14, Pixel cameras write it by default, and the container is an ordinary JPEG with the gain map tucked into a multi-picture structure and described in XMP metadata. Google's open-source libultrahdr library is the reference implementation.
• Adaptive HDR is Apple's name for its adoption of the ISO standard, added with iOS 18, iPadOS 18, and macOS Sequoia in September 2024. iPhones had been writing an earlier, Apple-specific gain map for years before that; the standardized one is what makes those files readable elsewhere.
• ISO 21496-1 is the standard both now share. ISO published it in July 2025 as "Gain map metadata for image conversion, Part 1: Dynamic range conversion" (ISO 21496-1:2025), and Android 15 writes both its own metadata and the ISO metadata into the same file so a Pixel photo opens correctly on an iPhone and vice versa.

The practical takeaway: a "real" HDR photo from a phone is not a special format. It is a JPEG (or HEIC) with a map inside. That is why it opens everywhere, and also why it is so easy to lose the map without noticing.

The three reasons an HDR photo goes flat

Almost every "my HDR photo looks flat" complaint comes down to one of three causes, and forum threads tend to blur them together: the viewer is not rendering the map, the platform stripped the map, or the destination is physically SDR. A typical Adobe Community thread opens with a photo that "looks great in Lightroom" and then, once exported and opened from a folder, looks "flat and over exposed"; the replies in that same thread cover all three causes without ever separating them.

1. The viewer ignores the map. Most desktop image viewers, most email clients, most operating-system previews, and Firefox as of this writing show the SDR base and nothing else. The file is intact. Open the same file on a recent iPhone or Pixel in the native gallery, or in Safari 26 or a current Chromium browser on an HDR-capable screen, and the highlights come back. If a file looks flat on one device and correct on another, this is the cause, and there is nothing to fix in the file.

2. The pipeline stripped the map. A gain map is metadata plus an auxiliary image, and any process that re-encodes the picture without understanding it throws both away. Users on the Squarespace forum report exactly this: "Squarespace strips the JPEG Gain Map metadata from the file." Many social uploads through a desktop browser do the same. Some editing operations do it by necessity (see the section on edits below). Once the map is gone, no viewer can restore it, because the map was measured at capture time and cannot be recomputed from an 8-bit base image.

3. The destination is SDR by nature. Prints, projectors, most office monitors, and any PDF are standard range. An HDR edit that pushes highlights above paper white will always land flat on paper, because there is no brighter-than-white on paper. This is the case people most often mistake for a bug.

Diagnosing which one you have takes about a minute: view the file on a phone that shot HDR in the first place. If it glows there, the map survived and you have a viewer or destination problem. If it is flat there too, the map is gone.

Where HDR photos actually display right now

As of mid-2026, gain-map photos display correctly in the native photo apps of recent iPhones and Android phones, in Safari 26 and Chromium-based browsers, and on Instagram and Threads, while Firefox, most desktop viewers, and most website builders still show only the SDR base. The support picture moves quarterly, so treat this as a snapshot rather than a table of record.

Browsers. WebKit's release notes are unambiguous: "in Safari 26.0 for iOS 26, iPadOS 26, macOS 26 and visionOS 26, WebKit adds support for HDR images on the web," alongside a new CSS dynamic-range-limit property that lets a page choose between full HDR and a standard-range rendering (WebKit Features in Safari 26.0). Chromium browsers (Chrome, Edge, Brave, Opera) added Ultra HDR display support earlier. Firefox has an open request for ISO 21496-1 support with no committed date. There is no caniuse.com entry for gain-map images yet, so check on a real device rather than a compatibility table.

Phones. Android 14 and later render Ultra HDR in the system gallery and Google Photos; iOS 18 and later render both Apple's own and ISO gain maps in Photos. These are also the screens with the most headroom to show: Apple lists the iPhone 16 Pro at 1,000 nits typical, 1,600 nits HDR peak (Apple tech specs), and Google lists the Pixel 9 Pro at up to 2,000 nits in HDR mode. A gain map that looks dramatic on either of those will look gentler on a laptop that tops out much lower, which is by design.

Social platforms. Meta announced HDR photo support for Instagram in March 2024, built on gain maps so a post "can be displayed on any monitor regardless of whether it supports HDR or just SDR." The practical caveats, documented by photographers rather than by Meta, are that Stories do not carry HDR, some capture modes lack a map, and uploading through a desktop browser often drops it. Post from the phone, from the native app, to keep it.

Website builders and CMSs. This is the weakest link. Any platform that re-encodes uploads on its own pipeline will keep the map only if that pipeline understands it, and most do not yet; user reports of stripped maps on Squarespace have gone unanswered. If HDR on your own site matters, host the file you produced rather than letting the platform regenerate it, and confirm in Safari 26 or Chrome on an HDR screen.

Ready to check your own file? Convert SDR to HDR returns an Ultra HDR JPEG and tells you in the response whether the map was preserved, generated, or absent.

Check whether your screen shows HDR

The fastest way to know whether what you are looking at can render a gain map is to view the same photo twice, once as a plain JPEG and once as an Ultra HDR JPEG, and see whether they differ. On the SDR to HDR converter page we keep exactly that pair side by side: if the right-hand image is visibly brighter in the highlights, your screen and browser are rendering HDR; if the two look identical, you are seeing the standard-range base of both.

Identical is not a fault. It means one of two things: the display has no headroom above white (most office monitors, many laptops, every projector), or the browser does not read gain maps yet (Firefox, most desktop viewers). Open the same page on a recent iPhone or Android phone and the difference appears, which is also the quickest way to confirm a file of your own still carries its map: convert it, then view the result on a phone that renders HDR.

This test is worth running before you blame an export. A surprising number of "my HDR photo went flat" complaints are looked at on a screen that could never have shown the difference in the first place.

Which formats can carry HDR (and which cannot)

Only two mainstream formats carry a gain map in a way that falls back cleanly: JPEG (as Ultra HDR) and HEIC, with AVIF and JPEG XL taking a different route by storing HDR in the pixels themselves, and WebP and PNG unable to represent HDR at all in common use. Which one you choose decides whether the photo survives the trip.

• JPEG with a gain map (Ultra HDR). The safest choice for sharing, because the fallback is an ordinary JPEG. Lightroom's own documentation describes a JPEG export from an HDR edit as saving "an SDR image with HDR details preserved with a Gain map" (Adobe, HDR output). The map adds a few percent to file size because it is stored at reduced resolution and compressed hard.
• HEIC / HEIF. What iPhones and many cameras write natively, with the gain map inside the container. Excellent on Apple hardware; support elsewhere is patchier, which is why so many workflows convert to JPEG for delivery. If you are converting camera HEIF files, our HEIF to JPG conversion guide covers the general path.
• AVIF. Can hold true 10-bit HDR in PQ or HLG, and Adobe recommends it for HDR export because of the higher bit depth and smaller files. But that is HDR in the pixels, not a gain map over an SDR base: a viewer that does not do HDR does not get a clean fallback. AVIF also carries an ISO gain map in newer encoders, but that path is still uncommon. Our explainer on what an AVIF file is covers the format's wider tradeoffs.
• JPEG XL. HDR-native, stored as floating-point pixel data; also listed by Adobe as an HDR-capable export. Like AVIF, there is nothing to synthesize a gain map into, so a JXL file is HDR only if the source was.
• WebP. Cannot represent HDR in any form.
• PNG. The third edition of the PNG specification adds a cICP chunk for native HDR color signaling (W3C PNG Third Edition), a different mechanism with no SDR fallback layer; a separate proposal to add gain maps to PNG remains an open issue, not part of the spec. For sharing purposes today, treat PNG as SDR.

If the goal is "everyone sees a good photo and HDR screens see a better one," JPEG with a gain map is the format that delivers it. It is also the only output on our HDR converter that carries one, for exactly the reasons above.

The edits that switch HDR off

Any edit that changes the base image invalidates the gain map, because the map is a ratio relative to that base, and honest tools return a clean SDR file rather than a file labeled HDR that no longer is. This is the least understood cause of flat exports, and it is not a bug in the editor.

Think of the map as "multiply this pixel by this much." Brighten the base image by half a stop and the multiplier now points at a different starting value; applying it would overshoot. Sharpen through a bounded color space and everything above standard white is clipped before the map is even consulted. Remove a background and composite the subject onto a new one, and the compositing math runs on 0 to 255 values that have no concept of headroom. Generate a drop shadow and the same applies.

So a workflow that shoots HDR, then adjusts brightness, sharpens, and cuts out the subject, ends with an SDR file no matter how careful each step was. That is not a reason to avoid those edits. It is a reason to sequence them: do the destructive edits first, on the base image, then produce the HDR deliverable last, from a source that still has its map, or by generating a map for the finished SDR result.

Mochify Workflow: keep the gain map, or add one

Mochify's SDR to HDR converter takes any photo and returns an Ultra HDR JPEG, preserving the gain map if the file already has one and synthesizing a plausible one if it does not, so the same tool handles a Pixel capture that needs to survive a resize and a plain JPEG that never had headroom. The lane is decided by the file, not by a setting.

curl -X POST "https://api.mochify.app/v1/squish?type=jpg&hdr=generate" \
  -H "Authorization: Bearer $MOCHIFY_KEY" \
  --data-binary @photo.jpg \
  -D headers.txt -o photo-hdr.jpg

grep X-Mochify-HDR headers.txt
# X-Mochify-HDR: generated

On the HDR path only the quality parameter reaches the encoder; optimizeForWeb is accepted but has no effect, because progressive scan and chroma subsampling belong to the plain JPEG writer that an Ultra HDR request does not go through. The encoder is Google's jpegli across the whole pipeline, which is what keeps the map close to free: better quality per byte on the base image pays for the extra layer, and the map itself usually lands in the low single-digit percentages. The jpegli guide covers why that matters for every JPEG, HDR or not.

Cheat Sheet: does this keep my gain map?

FAQ