Your colors washed out after upload.
There are two causes, and they are easy to tell apart.

A QuickTime file can carry a colr extension. It holds three indices: colour primaries, transfer function and matrix. Index 1 is ITU-R BT.709 for each of the three, which is why a Rec. 709 HD file is described by the triplet 1-1-1. Those three numbers are not the picture. They are the note attached to the picture saying which colour space it was authored in, so that whatever opens the file next applies the right transform rather than a guessed one.

Apple also documents the precedence rule. The colr extension supersedes the older gama extension: a writer should never put both in an image description, and a reader must ignore gama when colr is present. That single sentence is why files written by older tools, or by pipelines that still emit a gamma value alongside a colour tag, behave inconsistently as they pass from one application to another.

The consequential part is what happens when the tag is absent. Apple Technical Note TN2227 states it plainly: media without an nclc tag is colour managed by QuickTime X as if it were created in the SMPTE-C colour space. Your Rec. 709 export, untagged, is therefore read as something it is not, and a transform is applied that you never asked for. That is the documented route by which an untagged Rec. 709 file shifts. BT.709 itself is not ambiguous or outdated: the current version is BT.709-6, approved in June 2015 and in force. The standard is settled. What is missing from a shifted file is the sentence saying the file follows it.

What you do about it is short. Tag the export Rec. 709 explicitly rather than leaving the encoder to write a default, because a default that is right on your machine today is not a property of the file. Then check the tag on the finished file before you send it, the same way you check duration and audio channels. A file that says what it is survives every hop after that: another editor’s machine, a client’s laptop, a platform’s transcoder. A file that says nothing is at the mercy of whatever each of them assumes.

Vimeo describes its transcoding this way: during the transcoding process, your video file is re-encoded into several formats that will be available to view on Vimeo. YouTube, on its Help page for Content Manager partners, states that YouTube always re-encodes videos to optimize their playback quality, and elsewhere that a video is converted to the highest resolution available to ensure successful playback across devices and networks. Neither statement is a criticism. Both are load-bearing engineering: a platform serving millions of devices cannot ship one file to all of them. But it means the picture your client is judging is a derived file, and every property of it, colour included, was decided by that pipeline.

YouTube also publishes what its pipeline expects, which is worth stating because it tells you what to hand it. Its recommended upload settings name BT.709 as the SDR colour space, H.264 in High Profile, 4:2:0 chroma subsampling, and encoding at the frame rate the footage was recorded at. Vimeo’s recommendations agree on H.264 High Profile and add a constant frame rate and a constant rate factor of 18 or below. When you feed a pipeline the input it documents, you remove the part of the outcome that is your responsibility. What remains is theirs.

Then there is the cause almost every article on this subject misses, and it is the cheapest of all to rule out. YouTube states that when you upload a video, it is initially processed in low quality, that higher qualities process afterwards, and that a video may seem to be missing higher qualities for several hours. Its own worked example is a 60-minute 4K 30 fps video taking up to four hours to finish high-resolution processing. A video judged in the first hour after upload may simply not be finished. If you sent a client a link ten minutes after uploading and they replied that it looks flat and soft, the honest first answer is to ask them to look again tomorrow.

Resolution matters here too, for a reason that is not obvious. Vimeo gates its renditions on the uploaded file’s dimensions: the 4K rendition is generated only when the larger dimension is at least 3,648 pixels or the smaller is at least 2,052; the 2K rendition needs 2,432 or 1,368. Upload just under a gate and the top rendition is never made, so the viewer gets a smaller one, which reads as soft and flat even when nothing is wrong with your colour at all.

uncompressed.io streams the exact bytes you upload. There is no transcode anywhere in the path, of video or of audio. MP4 or MOV, H.264, HEVC or AV1, up to 50 GB per file, delivered as uploaded. The consequence for colour is narrow and real: there is no second encoder in the chain, so there is no second colour transform between your export and your viewer’s player. The file the viewer receives carries the tag you wrote, because it is the file you wrote. Cause two does not exist here, because the mechanism that produces it does not exist here.

Now the part that matters more than the claim. That does not make colour correct on the viewer’s screen, and nothing any host can build ever will. The viewer’s display, its calibration, its brightness setting and their browser still do the final rendering, on our player and on every other. A client watching on an uncalibrated laptop at half brightness in a bright room is going to describe your grade as dark, and there is no hosting decision that changes that. We will not claim otherwise, and a vendor who does is selling you something that is not theirs to sell.

There is a second honest trade to state alongside it. There is no adaptive ladder here, because building one would mean re-encoding. So a viewer on a slow connection buffers instead of silently sliding to a mushy rendition. That is the correct behaviour for reviewing a grade, where a quiet downgrade is worse than a pause, and the wrong behaviour for casual reach, where a pause is worse than a downgrade. Playback also depends on the viewer’s hardware decoder: a high-bitrate master plays when their machine can decode it, and their machine is not something we control either.

If your local player already shows the wash before the file is uploaded anywhere, no host on earth improves it. A host that re-encodes will re-encode a washed-out file. A host that does not re-encode will faithfully deliver a washed-out file. The fix is an export setting on your machine, it costs one re-export, and the two-minute local test tells you that before you spend a weekend moving anything. Run the test first. If it points at cause one, close this page and go fix the tag.

There are also good reasons to keep publishing where you publish. YouTube is unbeatable for reach and discovery, it costs nothing, and no private host substitutes for an audience. Vimeo’s player, marketing tools and OTT products have no equivalent here. Both platforms are doing the re-encode for a reason: they are delivering to every device and connection there is. If what you need is reach, the re-encode is the price of the reach and it is a fair one. If what you need is for a colourist, a director or a client to judge the actual grade, that is the case where the derived file is the wrong object to be looking at, and where a host that hands over the original bytes is doing something a ladder cannot.

Most people reading this need both, on different days. The useful split is to keep the public cut where the audience is, and send the copy that decisions get made on somewhere that does not touch it.