Why Does My HDR Photo Look Different on Every Screen?
You export an HDR photo from Lightroom, open it in Google Photos, check it in a browser, and see a different result in each place. That is usually not a bad export. HDR photos can contain more than one valid rendition, and each app decides how to read that data. This guide explains the moving parts: the SDR base, the gain map, the display headroom, and the destination app. It also gives you a reliable workflow for sharing HDR photos in 2026.
See the difference
The short answer
An HDR photo is not only a brighter JPEG. A gain-map image stores a normal SDR rendition plus extra instructions for an HDR-capable display. A compatible viewer combines both; a viewer that does not support the gain map shows the SDR base instead. The same file can therefore be valid in both cases but look different: on an HDR display, bright areas can render above ordinary SDR white; on an SDR display, the file falls back to its normal base image; and in an app that re-encodes or ignores the metadata, the gain-map effect may be reduced or lost.
What is inside an HDR photo?
Modern gain-map HDR is designed to be backward compatible. The file carries a baseline SDR image that ordinary software can open, a gain map with per-pixel instructions for the HDR boost, and metadata with the values needed to decode, scale and apply that map. The HDR display provides the headroom that makes the extra brightness visible. ISO 21496-1:2025 formalizes this dynamic-range conversion model. Google Ultra HDR and Apple gain-map photos are related implementations of the same general idea, but their container and metadata details are not interchangeable in every workflow. The gain map does not rescue detail already clipped in the source: if a window is flat white in the source JPEG, it cannot recreate the missing texture.
Why Lightroom, Google Photos and Reddit can disagree
The SonyAlpha discussion that inspired this guide shows the real-world friction clearly: the photographer edited in HDR, Google Photos displayed the Ultra HDR JPEG, and the group still had to reason about SDR, gain maps, display headroom and platform compression. Lightroom is the authoring step; its HDR Output can save a JPEG with an SDR image and a gain map, and it can also work with AVIF and JPEG XL. Adobe recommends JPEG for sharing and TIFF or PSD when more HDR editing is still required. Google Photos supports Ultra HDR and can render the HDR rendition when the device and screen support HDR; otherwise it displays the SDR fallback. Reddit and other services may resize, recompress or strip auxiliary metadata, so the photographer reports that Reddit compression did not do the HDR image justice. Treat that as a warning to verify the downloaded destination copy, not as a universal claim. Finally, two HDR devices can show different brightness because peak luminance, brightness settings, operating systems and viewers vary.
JPEG Ultra HDR, AVIF, JPEG XL or HEIC?
There is no single best format for every destination. A JPEG with a gain map or Ultra HDR is the safest broad-sharing choice because it keeps a usable SDR fallback, although the HDR layer still depends on the viewer. AVIF fits modern web pipelines that control the viewer, with efficient compression and higher bit depth but less predictable destination support. JPEG XL is useful when the workflow explicitly supports it. HEIF or HEIC fits Apple-focused libraries but has narrower interoperability outside that ecosystem. TIFF or PSD is best kept as a working master for further editing, not casual sharing. For a public link or mixed audience, deliver a gain-map JPEG and keep the high-quality master separately.
A reliable HDR sharing workflow
1. Keep the master: retain the RAW, TIFF or PSD version for future edits. 2. Export the delivery file: use a gain-map JPEG when compatibility matters most, and use AVIF or JPEG XL only after verifying destination support. 3. Check both renditions: open the export on an HDR display and on an SDR display; the HDR view should show extra highlight headroom while the SDR view remains coherent. 4. Test the destination copy: download the image back from the service or open its public URL instead of assuming the upload is byte-for-byte identical. 5. Share the original when fidelity matters: a link to the original file or a service known to preserve gain-map metadata is safer than an unknown social-media re-encode.
Where MakeHDR fits
MakeHDR is the delivery step after your image already looks right. It can turn a finished JPEG, PNG or HEIC into a gain-map Ultra HDR JPEG locally in the browser. The conversion is deterministic, uses the pixels in your file, and does not upload the image or invent detail. If the source is already clipped, the gain map cannot recover what is no longer there. The practical path is: finish the image in the editor you trust, create the gain-map delivery file, verify it on HDR and SDR screens, then share the version the destination preserves.
Sources and verification notes
This guide was checked against ISO 21496-1:2025, Google Ultra HDR Image Format and the libultrahdr reference codec, Apple Developer gain-map documentation, Adobe Lightroom HDR Output documentation, and Google Photos HDR help. The SonyAlpha thread is used as a field observation, not as proof of universal platform behavior.