You converted a clip to HDR10. Whether anyone sees it as HDR now depends on three things lining up: the display, the player, and the platform. Any one of them can hand you SDR back.
Displays that show it
Reliable
- HDR TVs from roughly 2018 onward. Nearly all of them accept HDR10; it is the format that requires no licensing.
- iPhone 12 and later. The panel and the video pipeline both handle HDR10, and playback visibly drives brighter than the surrounding interface.
- iPad Pro with a Liquid Retina XDR display, and MacBook Pro with XDR.
- Recent Android flagships, though behavior varies more by manufacturer than on iOS.
Unreliable
- Standard laptop and desktop monitors. Many advertise "HDR support" with 300–400 nits of peak brightness and 8-bit panels, which means they accept the signal and then tone-map it into a range that cannot show it. The file is fine; the screen is the bottleneck.
- Anything connected over an older HDMI cable or through a hub that negotiates down. HDR10 at 4K60 needs the bandwidth.
The practical test: play a known-good HDR clip next to an SDR one on the same screen. If the HDR clip does not get visibly brighter in the highlights, the display is tone-mapping.
If the destination genuinely cannot take HDR and you need a matching SDR deliverable, do it deliberately rather than letting a player guess: converting HDR to SDR walks through three working methods.
Cable and connection bandwidth
A display that supports HDR10 and a cable that can carry it are not the same requirement, and the second one is where a lot of quietly wrong playback comes from.
HDMI 2.0 carries up to 18 Gbps, enough for 4K at 60 frames per second with 10-bit color, but only at 4:2:0 chroma subsampling. That covers most HDR10 delivery: a 4K60 HDR10 file over a 2.0-rated port and cable still shows full 10-bit range and gets the HDR flag through. HDMI 2.1 raises the ceiling to 48 Gbps, enough for 4K60 at full 4:4:4 or 4:2:2 color without subsampling, and for higher frame rates like 4K120 that 2.0 cannot carry at all regardless of color settings.
Where this actually bites: an HDMI chain is only as capable as its weakest link. The port on the source device, the cable itself, and anything in between, a soundbar, an AV receiver, a cheap switch, all have their own HDMI version rating, and the connection negotiates down to whatever the least capable link supports. A receiver or switch stuck on HDMI 1.4 or an early 2.0 revision can silently drop 10-bit down to 8-bit, or drop the HDR flag entirely, while still showing a picture, so playback looks normal at a glance and nothing on screen tells you it happened. If a 4K HDR10 file looks flat specifically when routed through a receiver or a switch, and correct when the source connects straight to the TV, that is the chain, not the file.
Platforms
YouTube handles this properly. Upload the HDR10 file as-is, no special settings, no separate flag to tick. YouTube reads the metadata, transcodes to its own HDR ladder (VP9 and AV1), and serves HDR to viewers whose device supports it while auto-generating an SDR version for everyone else. You get both from one upload. Give it time: the HDR renditions often finish processing after the SDR ones, so a video can look SDR for the first while. One consequence of the VP9/AV1-only ladder: a viewer on an older browser or device that cannot decode either codec gets the SDR fallback automatically, with no error and no indication anything was skipped, so a video "not showing HDR" on an old tablet is usually a decoder limitation on the viewing end, not a problem with the upload.
Apple Photos and iMessage pass HDR through intact between Apple devices. This is the easiest way to actually see your own conversion, AirDrop it to your phone and play it in Photos.
Instagram, TikTok, and most short-form apps are inconsistent. Some ingest HDR and re-encode to SDR; some accept HDR on iOS and not on Android; behavior changes between app versions without announcement. All of them re-encode on ingest regardless, the inconsistent part is whether HDR metadata survives that re-encode, not whether re-encoding happens. The same file can come out differently depending on where you post it, a feed video, a Reel, and a Story on the same app sometimes run through different encode paths, so a result that held up in one placement is not a guarantee for another. Assume SDR delivery and treat any HDR that survives as a bonus. If a platform matters commercially, test with an unlisted or private post on the exact placement you intend to use before committing to a workflow.
Vimeo supports HDR on paid tiers. Web pages are the hardest case: browser HDR video support is genuinely partial, and a <video> tag on a normal page will often be tone-mapped even on capable hardware.
Android splits into two layers that do not always agree. A phone's screen can be genuinely HDR10-certified while the software on top of it still decodes conservatively. Google Photos and most manufacturers' own gallery apps handle HDR10 natively on recent versions, but a stock video player or a third-party app can tone-map by default even on hardware that could show the real thing. If a clip looks flat on an Android phone you already know supports HDR, try opening it specifically in Google Photos or the phone's default gallery before concluding the display is the problem, whatever app currently has the file open might be the layer that is falling back to SDR.
Smart TV apps versus casting
A TV playing a video through its own app and a TV displaying whatever a phone or laptop is sending it are two different pipelines, and only one of them reliably keeps HDR intact.
When a TV's own app, its built-in YouTube app, its Netflix app, whatever hosts the file, opens and decodes the video itself, the TV negotiates HDR the same way it would from any other native source: it reads the file's metadata and drives its panel accordingly. This is the reliable path, the same one the earlier practical test is checking.
Casting is less predictable, because "casting" covers two different things. Sending a native app a link or a file reference, so the TV's own app fetches and decodes it, behaves like the reliable path above, the TV is still doing the actual decode. Mirroring a phone or laptop screen, an AirPlay or system-level screen share that shows the TV whatever is currently rendered on the sending device's own display, is a different operation entirely: the sending device composites its screen, including its own SDR-rendered UI chrome, into a video stream and sends that. What arrives at the TV is effectively a recording of an SDR screen, regardless of what the original file was tagged as, because the HDR decode never happened on a pipeline that could pass the metadata through.
Practically: to actually see HDR on a TV, open the platform's own app on the TV and play the file there directly. If you have to cast, use a video app's built-in "cast" button, which hands the TV something to fetch and decode itself, rather than a generic screen mirror.
Editing and grading tools
If you are taking the converted file back into an edit, the project has to be set up for HDR or the NLE will tone-map on import:
- Premiere Pro: set the sequence color space to Rec. 2100 PQ.
- DaVinci Resolve: set the project color science and timeline color space to match; Resolve is the most predictable of the three.
- Final Cut Pro: set the library and project to Wide Gamut HDR.
Drop an HDR10 file into an SDR Rec. 709 timeline and it will look washed out and flat, that is the conversion to SDR happening at import, not a problem with the file.
What we hand you
A 10-bit H.265 MP4 with HDR10 metadata: smpte2084 transfer, bt2020 primaries, yuv420p10le pixel format. Resolution and frame rate identical to your source. No watermark.
That is the widest-compatibility HDR container available. We do not output Dolby Vision (it needs licensing and per-title metadata) or HLG (broadcast-oriented, and worse on the platforms most people actually publish to). For what actually separates the three, see HDR10 vs Dolby Vision vs HLG. If you have a specific delivery spec that requires either, HDR10 is a valid mezzanine to convert from.
Files are deleted after 7 days, so download the master and keep it somewhere you control.
Questions people ask
Does YouTube preserve HDR?
Yes. YouTube detects HDR10 on upload and serves an HDR stream to capable devices, falling back to SDR elsewhere. It is the most reliable public destination for HDR video, which is why it is worth uploading the HDR master rather than an SDR export.
Why does my HDR file look washed out in the browser?
Browser HDR support is genuinely partial, and a player that does not apply the PQ curve reads its code values as ordinary gamma: blacks lift and colour drains. Check the file's own metadata with ffprobe before concluding anything about the conversion.
Will messaging apps keep the HDR?
Generally not. Most re-encode on send, and re-encoding strips the metadata that lives in the HEVC stream. Share a download link rather than an attachment when the HDR version is the point.
If it looks wrong
Almost every "my HDR looks bad" case is one of five things:
- The display accepts HDR but cannot reach the brightness to show it.
- The browser or player is tone-mapping, try a native player.
- The editing timeline is set to SDR.
- The source clip had no range left to expand. See SDR vs HDR for why some footage converts better than others.
- Something in the connection chain, a cable, a switch, a receiver, negotiated down before the signal reached the display. See the connection section above.
For the conversion mechanics themselves, see how to convert an SDR video to HDR.