Your video looked right in the editor, you uploaded it, and the version on YouTube looks slightly off — flatter, cooler, a little more saturated, something you can see but struggle to name. The usual explanation you will find is "YouTube compressed it." That is rarely the interesting part.
YouTube publishes a table describing exactly what it does when a file's color metadata is missing or inconsistent, and it is not vague: when the tags are absent, YouTube assumes BT.709. If your file really is BT.709, that assumption costs you nothing. If it isn't, everything downstream is being read under the wrong description of what the numbers in your file mean.
What YouTube actually does with your color
YouTube's recommended upload encoding settings page states its baseline directly: "YouTube recommends BT.709 as the standard color space for SDR uploads:" — and then gives three separate fields, not one:
| Color Space | Color Transfer Characteristics (TRC) | Color Primaries | Color Matrix Coefficients |
|---|---|---|---|
| BT.709 | BT.709 (H.273 value: 1) | BT.709 (H.273 value 1) | BT.709 (H.273 value 1) |
That the recommendation is split into TRC, primaries and matrix is the first thing worth absorbing. These are three independent pieces of metadata that ride along inside the file, and an encoder can write one, two, all three, or none of them. "My export is BT.709" is a statement about your intent; whether the file says so is a separate question.
The second thing YouTube documents is that it normalises tags before it touches the video:
"YouTube standardizes functionally similar color matrices and primaries before processing the video. For example, BT.601 and BT.709 TRC are identical, and YouTube unifies them to BT.709. Or, BT.601 NTSC and PAL have functionally similar color matrices and YouTube unifies them to BT.601 NTSC."
Note the word functionally similar. This step is housekeeping — collapsing values that describe the same thing into one canonical label — and it happens before processing, so everything after it works from the unified tag rather than whatever your encoder originally wrote.
The assumption table, in plain terms
Here is the part almost nothing written about this topic mentions. YouTube lists four specific situations and what it does in each:
| When | YouTube Action |
|---|---|
| "The upload color space has unspecified TRC." | "Assumes BT.709 TRC." |
| "The upload color space has unknown or unspecified color matrix and primaries." | "Assumes BT.709 color matrix and primaries." |
| "The upload color space mixes BT.601 and BT.709 color primaries and matrix with specified values." | "Uses the color matrix to override the color primaries and make them consistent." |
| "The upload color space mixes BT.601 and BT.709 color primaries and matrix, and either primaries or matrix is unspecified." | "Uses the specified value of color primaries/matrix to set and override the unspecified one." |
Read as a group, those four rows describe the same move: in the cases YouTube lists, an unspecified field gets filled in — with BT.709 if nothing else in the file suggests otherwise, or with the file's own other field.
That is the mechanism behind a color shift you cannot trace to compression. The pixels arrived intact; the label describing how to interpret them was written by YouTube instead of by you.
Be precise about what YouTube is not claiming, though: the page describes assuming and unifying tags, not converting or destroying your grade. Rows three and four are conflict resolution — when primaries and matrix disagree the matrix wins, and when one of the pair is missing the specified one fills in the other.
The fastest fix: make your export say what it is
If you are working in SDR, the fix is to have your export match YouTube's stated baseline and to have it actually written into the file — BT.709 TRC, BT.709 primaries, BT.709 matrix. When the file's tags and YouTube's default assumption agree, there is nothing left for YouTube to guess at.
Where that setting lives depends on your editor — look for a color space, color management or color tag option in the export dialog rather than trusting the preset name, and check your editor's documentation for how it writes those fields.
The rest of YouTube's recommended settings are worth matching while you are in there: "Video codec: H.264", "High Profile", "Chroma subsampling: 4:2:0", and "Variable bitrate. No bitrate limit is required, though we offer recommended bit rates below for reference" — its reference figure for 1080p SDR at 24/25/30 fps is 8 Mbps, and 10 Mbps for 1080p HDR.
One caveat about that page: it opens with "These features are only available to partners who use YouTube Studio Content Manager." and "Below are recommended upload encoding settings for your videos on YouTube." These are recommendations, not entry requirements — an ordinary MP4 that misses several of them still uploads fine.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
If you are re-encoding before upload anyway — because the file is enormous, or because it came out of a screen recorder rather than an editor — the compressor above does it in your browser tab. The file is read from disk, re-encoded locally and handed back, so nothing is uploaded to a server on the way to fixing an upload problem. For the trade-offs behind the settings, how to compress a video without losing quality covers what bitrate and resolution each cost you, and the compress video tool page covers the same job outside a YouTube context.
Other causes, in order of likelihood
- Your file specifies some tags and not others. This is row four: YouTube "Uses the specified value of color primaries/matrix to set and override the unspecified one." A half-tagged file is not neutral — the present field decides the absent one.
- Primaries and matrix in your file disagree. Row three: YouTube "Uses the color matrix to override the color primaries and make them consistent." If your export writes a BT.601 matrix with BT.709 primaries, the matrix is what survives.
- Your source is BT.601. BT.601 and BT.709 TRC are described as identical and unified to BT.709; BT.601 NTSC and PAL matrices are unified to BT.601 NTSC. This is relabelling of functionally similar values, not a regrade.
- Processing may not have finished. YouTube says "Your video will be converted to the highest resolution available to ensure successful playback on different devices and networks", and separately that "Higher qualities such as 4K or HD may take more time to process." It gives no figure for how long that takes.
- Your browser can't play the version you are trying to judge. YouTube's note on 4K is explicit: "To view new 4K uploads in 4K, use a browser or device that supports VP9."
- You are uploading HDR at a small frame size. YouTube's recommended-bitrate table for HDR uploads lists 480p and 360p as "Not supported" — it gives no HDR bitrate recommendation at those resolutions at all.
What YouTube's help pages do not document is what its transcode does beyond the tag handling above — which codec it re-encodes into under what conditions, or what output bitrate it lands on. Those rules are not published; check the official documentation rather than any third-party chart claiming to know them.
How to tell it worked
Compare like for like. Wait until processing has finished, play the YouTube version at the same resolution as your local file, and check the two side by side on the same screen — not the upload on a phone against the export on your grading monitor. Then confirm the export you just made carries the three BT.709 fields, rather than assuming the preset wrote them.
FAQ
Why does my video look washed out after uploading to YouTube? The most commonly overlooked cause is missing color metadata. YouTube's own table says that if the upload "has unspecified TRC" it "Assumes BT.709 TRC", and the same for an unknown or unspecified matrix and primaries. A file that is not actually BT.709 but carries no tags gets interpreted as though it were.
Does YouTube change my video's color space? It standardises tags. YouTube says it "standardizes functionally similar color matrices and primaries before processing the video", giving BT.601 and BT.709 TRC being unified to BT.709 as its own example. Beyond that normalisation and the assumptions in its table, its transcode behaviour is not documented.
What color space should I export in for YouTube? For SDR, BT.709 — YouTube states it "recommends BT.709 as the standard color space for SDR uploads", specified across all three fields: TRC, primaries and matrix coefficients.
Will re-exporting at a higher bitrate fix the color? Not on its own. Compression changes how precisely pixel values are stored; a color space mismatch changes what those values are taken to mean. YouTube states "No bitrate limit is required", so bitrate does not change what it assumes about your color space. Fix the tags first.
Does any of this apply to Shorts? The color space guidance is about the upload file, so it applies to whatever you upload. Shorts have their own separate constraints on length, aspect ratio and resolution — see our YouTube Shorts specs breakdown, and YouTube video too large to upload for the size and duration ceilings.
More troubleshooting write-ups in the fix archive, and all Clapr tools run in your browser rather than on a server. Color space details cited from YouTube's official recommended upload encoding settings page, checked 16 September 2026 — verify against the official documentation before relying on them.
