Upload High Dynamic Range (HDR) videos

You can upload High Dynamic Range (HDR) video content to YouTube. HDR videos show higher contrast and more colors than standard digital video.

Viewers can watch HDR videos on compatible mobile devices and HDR TVs. They can also stream HDR videos using Chromecast Ultra to an HDR TV. Viewers can confirm HDR playback when a video is played if they see an "HDR" badge on the playback controls or in the quality menu.

Viewers watching on non-HDR devices will see the video as a standard dynamic range (SDR) video.

Upload HDR videos

HDR videos must have HDR metadata in the codec or container to be played back properly on YouTube. The most reliable way to properly record the metadata is to export from a supported application.

If you use a workflow for color grading that doesn't export standard HDR metadata, then you can use the YouTube HDR metadata tool to add HDR metadata to a video. This tool will only work correctly if your video was graded using an HDR transfer function. 

Note: If you aren't sure if your video was graded using an HDR transfer function, using this tool will badly distort your videos. Many things that have "HDR" in the title were not graded with an HDR transfer function, and this tool will not work on those videos. If you did not grade your own content in HDR, or don't know what it means to color grade a video, you should not use the YouTube HDR metadata tool.

If you are grading your video, take care to grade in Rec. 2020 with PQ or HLG. Using a different configuration, including DCI P3, will produce incorrect results.

Once a video has been properly marked as HDR, uploading it follows the same process as a normal video upload. YouTube will detect the HDR metadata and process it, producing HDR transcodes for HDR devices and an SDR downconversion for other devices.

Note: HDR videos currently can't be edited with YouTube Web editor.

HDR video requirements 

Once you upload a video, YouTube supports all resolutions and will auto-convert HDR video to SDR videos when necessary.

Upload requirements

Resolution 720p, 1080p, 1440p, 2160p
For best results, use UHD rather than DCI widths (e.g. 3840x1600 instead of 4096x1716).
Frame rate 23.976, 24, 25, 29.97, 30, 48, 50, 59.94, 60 
Color depth 10 or 12 bits
Color primaries Rec. 2020
Color matrix Rec. 2020 non-constant luminance
EOTF PQ or HLG (Rec. 2100)
Video bitrate For H.264, use the recommended upload encoding setting
Audio Same as the recommended upload encoding setting

HDR video file encoding

The container and codec pairs below have been tested to work. Other high-quality 10-bit codecs with HDR metadata may also work. 

Container Encoding

H.264 10 bit

VP9 Profile 2

ProRes 422

ProRes 4444



H.264 10 bit

VP9 Profile 2



H.264 10 bit

VP9 Profile 2

ProRes 422

ProRes 4444


HDR metadata

In order to be processed, HDR videos must be tagged with the correct transfer function (PQ or HLG), color primaries (Rec. 2020), and matrix (Rec. 2020 non-constant luminance).
HDR videos using PQ signaling should also contain information about the display it was mastered on (SMPTE ST 2086 mastering metadata) and about the brightness of the content (CEA 861-3 MaxFALL and MaxCLL). If it's missing, we use the values for the Sony BVM-X300 mastering display, which is the most commonly used HDR mastering display at this time.
Optionally, HDR videos may contain dynamic (HDR10+) metadata as ITU-T T.35 terminal codes or as SEI headers.

HDR authoring tools 

The following are examples of tools you can use to upload HDR videos to YouTube:

  • DaVinci Resolve
  • Adobe Premiere Pro
  • Adobe After Effects
  • Final Cut Pro X

Common issues

Incorrect color space marking

In cinema, it's common to master HDR content in the DCI P3 color space, with either the DCI (~D50) or D65 white points. This is not a supported format for delivery to consumer electronics. When mastering, choose Rec. 2020 color primaries (the Rec. 2100 standard implies Rec. 2020 color in many applications).
A common mistake is to master in P3, then tag the result using Rec. 2020 primaries. This will result in an oversaturated look with shifted hues.

More control over SDR conversion

YouTube's automated SDR downconversion is a convenient choice that can deliver good results with no effort. However, on challenging clips, it might not deliver the perfect result. We're working on improving automated SDR downconversion so that it works great for all material.
It's possible to provide a hint to YouTube's SDR downconversion in the form of a 3D Look-Up Table, or LUT. To produce this LUT:
  1. Start by loading your HDR deliverable into a color grading application without applying any color management.
  2. Set your mastering display to Rec. 709 color and Gamma 2.4 transfer function.
  3. Apply an existing LUT that converts from Rec. 2020 + ST. 2084 to Rec. 709, and then in subsequent nodes, adjust primary correctors, curves, and keys to get the look you want.
  4. Export the LUT in the .cube format to the same folder as the HDR deliverable.
  5. Select both the LUT and the HDR video, and drag and drop them on the metadata tool.

The tool will apply metadata for the BVM-X300, and also pack in the LUT to provide hints to the SDR downconversion. 

Note: Currently, there is no spatial or temporal control for hinting the SDR downconversion. This means power windows and keys involving controls like Blur, won't work properly, nor will adjustments that apply to individual shots.

Noise in the shadows

When mastering in PQ (ST 2084), much of the signal range is devoted to shadow detail. Digital intermediate codecs like ProRes and DNxHR retain detail across the image range. This means your videos can end up with lots of noise in darker image regions that might be visually masked by highlights in the image.
YouTube's video processing may remove some noise to achieve streaming bitrates. You can get more control by denoising your video before rendering it for upload. Denoising can also help if your video looks too "compressed" when streamed.
We're always working to improve the quality of YouTube videos end-to-end, including handling this case better.
Was this helpful?
How can we improve it?