Diagnosis, then the fix
The banding is usually not in your grade. It arrives when the platform re-encodes your file and its rate control picks a coarser quantisation step than your export did. Here is a two-minute test that tells you which one you have, the mechanism in plain language, and the fixes in the order that helps most.
No credit card required. Cancel any time.
Updated September 2026
Start here
Almost everyone who lands on this page has already stared at the same sky, the same skin falloff or the same lens flare in their timeline and seen nothing wrong with it. That instinct is usually right. Before you touch a single node, settle the question properly, because the fix for a grade problem and the fix for an encode problem have nothing in common.
Find the single frame where the banding is ugliest and write down its timecode. One frame is enough, and a specific frame keeps you from comparing two different moments and drawing the wrong conclusion.
A lossless still from your timeline is your grade with no codec, no rate control and no quantisation anywhere in the chain. Whatever this file shows is what you actually made.
Full-screen the platform player on the same monitor you graded on, set the quality menu to the highest option it offers, and step to the same timecode. A browser window at 60 percent zoom against a full-screen NLE viewer will mislead you every time, because non-integer scaling invents contours of its own.
Bands in the still means the banding is in your grade and it will follow the file to every host on earth. A clean still and a banded stream means the banding was added after you exported, and everything below this point applies to you.
One extra check worth thirty seconds
The mechanism
This is not a mystery, and it does not need a conspiracy theory about platforms degrading your work. It is the ordinary behaviour of every block-based video codec, and a smooth gradient is the one kind of picture that shows it off.
Every codec in normal use splits the picture into blocks and transforms each block from pixels into frequency coefficients. A gradient is a slowly varying signal, so almost all of its energy lands in the lowest-frequency coefficients: the average level of the block and a gentle tilt across it. There is very little high-frequency content to carry, which is exactly why gradients compress so efficiently and exactly why they break so visibly.
The encoder then quantises those coefficients. It divides each one by a step size and rounds to an integer. The step size is not fixed; rate control sets it, frame by frame and block by block, to hit the bit budget it has been given. When bits are plentiful the step is fine and the rounding is invisible. When the budget tightens, the step gets coarser, and two adjacent regions whose true values differed by a single code value now round to the same value. The ramp stops being a ramp and becomes a staircase.
The last part is your eye, not the codec. Human vision exaggerates edges: a boundary between two flat patches that differ by one level reads as a hard contour, brighter on one side and darker on the other than either patch really is. That is why banding looks so much worse than the underlying error measures. A one-level step in a textured area is undetectable. The same one-level step across a clear sky draws a line you cannot stop seeing.
10-bit master
1,024 shades per channel. The night sky falls off smoothly, the way the camera saw it.
Crushed to 8-bit, then starved
256 shades, and aggressive quantization spends even fewer on dark areas. The falloff turns into visible bands.
Illustration rendered by your browser, exaggerated for visibility. The mechanism is real: fewer code values plus coarse quantization equals banding.
Detail masks quantisation error. In a textured area the rounding lands among frequencies the eye is already busy with, and the error disappears into the texture. A flat gradient has nothing to hide behind, so the same error is the only thing on screen. Rate control makes this worse rather than better: it spends bits where the measured error is largest, which is the busy part of the frame, and leaves the smooth part on a coarser step.
Video is stored with a non-linear transfer curve, so code values are not spread evenly across brightness. Near black, one code value covers a larger perceptual distance than it does in the highlights, and the eye is at its most sensitive to small luminance differences there. A night sky, a shadow falloff and an underexposed wall are the three shots that band first in almost every delivery.
Not because the viewer's display is 10-bit, which it often is not. Because the encoder is doing arithmetic. An 8-bit source offers 256 code values per channel; a 10-bit source offers 1,024. The finer scale means the value the encoder rounds to is closer to the value it wanted, and the residual error is smaller relative to the smallest step the eye can resolve. The benefit is in the encode, and it survives to an 8-bit screen.
Quantisation is not reversible. Once a ramp has been rounded into steps, those steps are the signal, and the next encoder faithfully preserves them and adds its own. An export of an export, or a graded file that already went through one delivery codec, arrives at the platform with banding baked in and gets a fresh layer on top.
What the platforms publish
This page builds its argument only on what the two platforms state on their own help pages. Neither Vimeo nor YouTube publishes the chroma subsampling or the bit depth of the renditions it delivers to viewers, so nothing here claims to know those. What both do publish is enough.
Vimeo states that during transcoding your file is re-encoded into several formats that will be available to view on Vimeo. It then does something unusual and useful: it publishes the maximum video bitrate of each rendition it delivers, and says plainly that those figures are a maximum and that a video could transcode at a lower bitrate depending on the complexity of the image.
Vimeo's own published maximum delivery bitrates per rendition, fetched 4 September 2026. Vimeo states that the bitrates listed for each resolution are a maximum and that a video could transcode at a lower bitrate depending on the complexity of the image, so read every figure as a ceiling and not as a promise. Above 4K, Vimeo delivers HEVC and publishes no bitrate figure at all.
Now connect that to the mechanism. Rate control sets the quantisation step to fit the bits it is allowed. A 4K frame carries roughly 8.3 million pixels. Twenty-two megabits per second across twenty-four of those frames is a real budget for most footage and a tight one for a slow, clean gradient held on screen, because a gradient offers rate control almost nothing to trade away. There is no detail to sacrifice first, so the step size itself has to grow. That is the whole causal chain: a fixed ceiling, a picture with no detail to give up, a coarser step, a contour.
For a sense of scale outside the two platforms, Apple publishes its own recommended HLS delivery ladder for the whole industry, and its top 4K HEVC rung is 16,800 kbps for SDR. Streaming as a category is built around a ceiling in that region. A graded master exported at 100 or 200 Mbps sits an order of magnitude above anything a streaming ladder is designed to carry, which is why the file you approved and the file your client watches are not the same picture.
YouTube is the opposite case, and the honest thing to say is that the numbers are not there. YouTube states, on its help page for partners using Content Manager, that YouTube always re-encodes videos to optimise their playback quality. It publishes a detailed set of recommended upload settings, including H.264 High Profile with 4:2:0 chroma subsampling for the file it asks you to send, and full SDR and HDR bitrate tables for that upload. It publishes nothing about the bitrate, the bit depth or the chroma subsampling of what it sends back to viewers. Any figure you have read for YouTube delivery is somebody’s measurement, not a Google statement, and this page does not use one.
The second YouTube fact, and it fixes more cases than you would think
The fixes
Every one of these is something you can do this afternoon. The first three do the heavy lifting; the rest close the remaining gaps and stop you from chasing a problem that is not there.
This is the single biggest lever. Give the platform's encoder 1,024 code values per channel to work from instead of 256 and its rounding lands on a much finer scale. Vimeo's recommended upload codecs include ProRes 422 HQ and HEVC alongside H.264, and YouTube's accepted upload formats include ProRes, DNxHR, CineForm and HEVC. Both routes get you a 10-bit master into the pipeline.
Dither adds a low-level random offset so the rounding error stops lining up along a contour and becomes noise your eye averages back into a smooth ramp. Fine grain does the same job and reads as intentional. Keep it light: random detail is expensive to encode and competes for the same bit budget that caused the banding.
Vimeo recommends this itself in its compression guidelines. A lower constant rate factor means a finer quantisation step and more bits spent on the parts of the frame that a fixed bitrate target would starve. Your upload gets bigger. That is the point: you are handing the platform's encoder a cleaner source to work from.
Both platforms publish what they want to receive, and both numbers are far above what they deliver. Meeting or exceeding the recommendation costs you nothing but upload time and removes your own export from the list of suspects.
Go from your timeline to the delivery file once. Never upload an export of an export, never re-wrap a file that has already been through a delivery codec, and never re-upload a file you downloaded back from a platform. Steps that are already baked in survive the next encode and collect a new layer of their own.
Vimeo produces its higher renditions only when your file's dimensions clear a published threshold. A 3200 by 1800 export does not qualify for the 4K rendition, so the best thing anyone can watch is the 2K rung at up to 12 Mbps, on a picture you thought was near-4K. Export to the standard frame size and the top rendition is actually generated.
The first version processed is a low-quality one, and higher qualities can take hours. Do not re-grade, re-export or re-upload on the strength of what a fresh upload looks like in its first hour. Confirm the quality menu is offering your resolution first.
For an approval, a colour review or a festival submission, the stream is the wrong artifact to argue about. Send the file itself alongside it. Whatever the platform does to its renditions, the person signing off has the picture you actually made.
Both platforms' published recommendations for the file you send them, fetched 4 September 2026. These are upload figures and nothing else. Vimeo's published delivery ceiling at 4K is 22 Mbps on its H.264 ladder; YouTube publishes no delivery figure at any resolution. YouTube's HDR recommendations are higher again, 44 to 56 Mbps at 4K for standard frame rates.
Vimeo's published rendition thresholds, fetched 4 September 2026. A file that misses a threshold simply never gets that rendition made, so the highest quality anyone can select is the rung below. This bites hardest on anamorphic and custom crops, where a frame that reads as 4K to you can fall under the gate.
The structural fix
Every fix above is a way of surviving a second quantisation pass in better shape. The other approach is not to have one.
uncompressed.io does not transcode. The player streams the exact bytes you uploaded, so the only encode in the chain is the one you performed and approved. If your export is clean, the stream is clean, because it is the same file. A 10-bit HEVC master is stored and served untouched, 4:2:2 included; whether any particular browser decodes a 4:2:2 file is the viewer’s decoder’s business, and no browser vendor documents it either way. Uploads are MP4 or MOV in H.264, HEVC or AV1, up to 50 GB per file.
1
quantisation pass
the one you chose in your own export
0
re-encodes on upload
the player streams the bytes you sent
50 GB
per file
MP4 or MOV, H.264, HEVC or AV1
5 GB
free to start
no credit card, no bandwidth meter
The honest caveats, both of them
When the banding is yours
This is the part most articles on this subject skip, and it is the part that saves people the most time. A meaningful share of banding complaints are not platform artifacts at all, and moving the file somewhere else will change nothing.
A heavy grade on 8-bit source material will band anywhere. An 8-bit capture recorded 256 values per channel and no more. Stretching contrast, lifting shadows, pushing a saturation curve or building a strong look on top of that footage spreads those 256 values further apart, and nothing downstream can put back values that were never recorded. The bands are in the picture from the moment the node is applied. A host that re-encodes will add to them. A host that does not re-encode will preserve them perfectly, which is not the same as fixing them.
The lossless still test at the top of this page separates the two cases in about two minutes, and there are two more tells worth knowing.
The bands are locked to the image. They sit in the same place on the same frame every single time, they show up in a PNG exported straight from the timeline, and they are visible in your local export before it goes anywhere near a platform.
The bands move and breathe. They shift with the picture, they look different between two viewings at different quality settings, and they are absent from both the lossless still and the local playback of the file you uploaded.
The bands appear only in a browser window at a non-integer zoom, or only on one particular screen. Scaling and display handling invent contours of their own. Compare full screen, at the same size, on the same monitor, before you conclude anything.
If the verdict is your grade, the fix is upstream of every platform: work from 10-bit source where the camera offers it, keep the grade in a high-precision working space, add dither at the end of the chain rather than the start, and be more careful about how far an 8-bit original is pushed. The delivery workflow guide covers that chain end to end; this page is about diagnosis and repair once the file is already out the door.
When you should stay exactly where you are
Questions
Because both platforms re-encode every upload, and the file the viewer plays is not the file you sent. Vimeo states that during transcoding your file is re-encoded into several formats. YouTube states that it always re-encodes videos to optimise playback quality. A second encode means a second round of quantisation, and quantisation is what turns a smooth ramp into visible steps when the step size gets coarse.
That question cannot be answered from published data, so this page will not pretend to answer it. Vimeo publishes maximum delivery bitrates per rendition, up to 22 Mbps at 4K on its H.264 ladder, and says the real output can be lower depending on the complexity of the image. YouTube publishes recommended upload settings and nothing at all about what it delivers to viewers. Comparing them would mean comparing a published ceiling against a number that does not exist.
Yes, and this surprises people. The benefit is not at the display, it is inside the encoder. A 10-bit source gives the encoder 1,024 code values per channel to work from instead of 256, so the values it rounds to sit on a finer scale and the rounding error is smaller relative to the step the eye can see. The output can still be watched on an 8-bit panel and look smoother than an 8-bit source would.
A small amount, yes, and dither is usually the better tool. Dither adds a low-level random offset before quantisation so the rounding error stops lining up along a contour and becomes noise the eye averages back into a smooth ramp. Grain does the same thing and also looks intentional. Both cost bitrate, because random detail is expensive to encode, so keep it fine and light. Heavy grain sent into a rate-limited encoder makes everything worse.
Not yet. YouTube states that a video is initially processed in low quality and that higher qualities can take several hours to appear, with a worked example of a 60-minute 4K 30 fps video taking up to four hours. Check the quality menu, confirm the resolution you expect is actually offered, and look again later before changing anything in your export.
Export one frame from your timeline as a PNG or TIFF. That is your grade with no codec, no rate control and no quantisation anywhere in the chain. If the still bands, the banding is yours and it will follow the file to every host on earth. If the still is clean and the stream is not, the banding was added after you exported.
No. The player streams the exact bytes you upload, so there is no second quantisation pass to introduce banding that was not already in your export. The honest trade is that there is no adaptive ladder, so a slow connection buffers rather than quietly dropping to a softer rendition, and playback depends on the viewer's own hardware decoder.
uncompressed.io streams the exact bytes you upload. No transcode, no second quantisation pass, so the gradient the viewer sees is the gradient you exported. Starter is free with 5 GB.