The answer first, then the reasoning
A grade lives in the bottom stops and in fine gradation. Those are precisely the things a rate-limited re-encode gives up first, and every platform that builds a rendition ladder is rate-limited by design. The honest recommendation has two halves: host the graded file somewhere nothing re-encodes it, and keep judging the grade itself on a calibrated display rather than in a browser.
No credit card required. Cancel any time.
Updated September 2026
The short answer
Those are two separate problems and most pages on this subject collapse them into one. The host controls whether the bytes survive the trip. Nothing about the host controls what the client’s panel does with them once they arrive.
Encode loss. If the platform re-encodes your upload into a ladder of renditions, the version your client presses play on is a new file made under a bitrate ceiling, and the ceiling is spent on the parts of the frame that are expensive to encode. A host that stores your file and streams those exact bytes removes that step entirely. There is nothing to tune, because nothing runs.
The reference environment. An uncalibrated laptop in a bright room is not a grading suite, and no delivery bitrate makes it one. For a real sign-off on a grade, calibrated local playback or a supervised session is still better than any web player, and this page will not pretend otherwise. Use a no-transcode host to take encode loss off the table, then argue about the picture on merit.
Why a grade is the worst case for an encoder
This is not a matter of taste or of a platform being stingy. It falls straight out of how rate-limited encoding allocates bits, and it explains why the shots you spent the longest on are the ones that come back wrong.
A grade puts its work in two places an encoder finds expensive. The first is the bottom of the range: a lifted-black look, a slow falloff into a shadow, a night exterior held two stops down. Fine differences between adjacent dark values are exactly what coarse quantization throws away, and the result is banding across a falloff you spent an hour shaping. The second is smooth gradation anywhere in the frame: a sky, a wall, a gel wash, a skin tone rolling off into shade. Those are large areas of tiny differences, which is the most bit-hungry thing a picture can contain and the easiest thing for an encoder to approximate away.
Add grain, and the problem compounds. Film grain is high-frequency noise across the entire frame, so it defeats the prediction between frames that modern codecs rely on and forces the encoder to spend real bits everywhere at once. A graded image with heavy grain and deep shadows is not an average video. It is the specific worst case, and it is what a colorist sends.
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.
The published numbers
Vimeo deserves credit here: it documents what it delivers, which most platforms do not. That transparency is also what makes the arithmetic easy to check.
22 Mbps
Vimeo 4K maximum, H.264
Top rung of the standard ladder.
16 Mbps
Vimeo 4K maximum, HDR and HEVC
Top rung of the HDR ladder.
30 to 60
Mbps Vimeo asks for at 4K
Its own recommended upload range.
0
Encodes that run here
The player is handed the stored file.
Vimeo’s own words
Read that against the previous section and the two halves lock together. The number is a ceiling, not a promise, and the thing that pulls a file below the ceiling is the complexity of the image. A graded frame with heavy grain and deep shadows is the complex image. The published maximum is therefore the best case for the work least likely to receive it.
The step before the ceiling matters just as much. Vimeo states that during the transcoding process your video file is re-encoded into several formats that will be available to view on Vimeo. There is no setting, plan or upload codec that skips it. Uploading a pristine master gives the encoder a cleaner source to work from, which is genuinely worth doing, but it does not change what the viewer is served.

Vimeo figures from Vimeo's guidelines for determining playback resolution, its video and audio compression guidelines, its FAQ on video transcoding and its article on watching videos above 4K, all fetched 5 September 2026. Vimeo states the delivery figures are maximums and that a video could transcode at a lower bitrate depending on the complexity of the image. uncompressed.io has no delivery figure to publish because it runs no encode; the 50 GB figure is the per-file upload ceiling.
What the no-transcode side actually is
The player is handed the stored master directly. There is no transcode step, no rendition ladder and no adaptive delivery anywhere in the path, which is why there is no delivery ceiling on this page to compare against Vimeo’s: there is no delivery encoder to have one. A 150 Mbps export plays at 150 Mbps. Files go up to 50 GB each, and no bandwidth is metered on any plan, including the free one. Storage is the only meter.
Three precise statements about codecs, because this is where marketing usually overreaches. First, we never re-encode, so a 10-bit 4:2:2 file is stored and served untouched, exactly as it left the suite. Second, whether a given browser decodes 10-bit 4:2:2 in a video element is not documented by any vendor, in either direction, so the honest instruction is to test the real file on the client’s real machine before you build a review around it. The page on 10-bit 4:2:2 browser playback sets out what is documented and what is not. Third, there is no codec allowlist in our code: what plays is decided by the viewer’s browser decoder, not by a platform rule. Camera RAW never streams anywhere, and the honest workflow is to finish to HEVC or ProRes and upload that. ProRes and DNxHR are hosted for client download rather than played in a browser. 8K plays when the viewer’s hardware decodes it.
And the cost of the trade, stated plainly. With no ladder there is no lower rung, so a viewer on a thin connection buffers instead of quietly sliding to a mushy version. For a public showreel that is a real drawback. For a grade going to four people who have to judge the picture, buffering for ten seconds and then seeing the actual image is the better failure mode, and it is the whole reason to choose this shape of host.
Practical
Any host can say the words. These four checks take about ten minutes and settle it with evidence, on whichever platform you are using today.
Before the review cut goes anywhere, make sure it contains a slow falloff into near-black, a wide area of smooth gradation and, if the show has grain, a grainy shot. Those three are the first casualties of a bitrate ceiling. A film that happens to open on a locked-off interview will look fine everywhere and tell you nothing.
Turn on the per-film download so the client can save what the page served, or save it yourself from the client's machine. On a host that stores and serves your master, that file should be byte-for-byte the export you uploaded, starting with an identical file size. On a platform that re-encodes, the download and the stream are different objects and the download may not be available at all.
Divide the file size by the duration and convert, or read it in any media information utility. That single number tells you whether what was delivered is your export or a rendition. If your 4K export left the suite at 150 Mbps and the delivered file works out to a small fraction of that, the ladder answered the question for you.
Pick a timecode inside the worst-case shot, export that frame from your own timeline, and have the client pause there and send a screen grab. Differences in banding and in grain structure are visible at a glance. Be honest about what this catches: it is a test of encode loss, not of display accuracy, because their panel, room and browser are still unknown variables.
The switch colorists reach for first
Streaming is often not the point of the delivery. A colorist frequently wants the client, the online editor or the finishing house to take the actual file rather than watch a version of it in a browser. Every film here carries an allow-download switch, and when it is on, the watch page issues a signed download URL so the viewer can save the master.
Two things worth knowing about it. It is per film, so a locked hero grade can be download-enabled while everything else in the library stays view-only, and it is not tier gated: it works on the free plan the same way it works on Vault. The single restriction is that it is forced off for a vaulted film, which is the point of vaulting. Compare that with Vimeo, where downloading from a video’s page is documented as a paid-plan feature, and where keeping your source file at all requires checking the Keep source video files box on a paid account, with Vimeo stating that source files may otherwise be deleted and may not be recoverable.
The honest limit
Say this to the client before the link goes out
The practical reading of that: use the host to make the remote look honest, and reserve the reference environment for the moments that need it. A no-transcode link plus a downloadable master covers most of the round trips in a job. The one session that decides the show is still worth doing properly.
When to stay where you are
If the finished piece is going out to an unknown audience on unknown devices, an adaptive ladder is the correct engineering and a single high-bitrate file is the wrong one. Graceful degradation on a hotel wifi network is worth more to that job than fidelity in the bottom stops, and the platform is doing work you would otherwise have to build. Grade for that ladder, deliver into it, and use a no-transcode host only for the approval round trip.
If notes, versions and approvals already run through a review tool with timecoded comments that the producer and the editor rely on, moving the review is a bigger disruption than the quality gain justifies. A process people actually follow beats a better picture nobody comments on. In that case, keep the review where it is and use a full-bitrate link or a direct download for the one pass where the grade is being judged.
Neither of those is a reason to accept a re-encode for the finishing pass. They are reasons to use two tools for two different jobs, which is normal. If you want the underlying mechanism in more depth, the guide on video hosting that does not compress covers the architecture, 10-bit video hosting covers bit depth end to end, and sending graded footage without banding is the practical version of the failure this whole page is about.
Questions
A host that performs no transcode, so the file the client watches is the file that left the suite. On uncompressed.io the player is fed the stored master directly and there is no encode step anywhere in the path, which means no published delivery ceiling and no rendition ladder. The trade is real and worth stating: with no lower rung to fall back to, a viewer on a poor connection buffers rather than quietly dropping to a softer version, and playback depends on that viewer's hardware decoder.
No, and no host can promise that. Removing the re-encode removes one variable, the one you cannot otherwise control. It does nothing about an uncalibrated laptop panel, a bright room, a browser's color management or a display that is not in the reference space you graded in. For a real grading review, calibrated local playback or a supervised session beats any web player. Use a host to remove the encode loss, not to replace the viewing environment.
You can upload it, and it is stored and served untouched, because nothing on our side re-encodes it. Whether a given browser decodes 10-bit 4:2:2 in a video element is not documented by any vendor, in either direction, so the only reliable answer is an empirical one: test the actual file on the actual machine your client will use before you build a review around it. If it does not decode there, the same file still works as a download.
Camera RAW never streams anywhere; the honest workflow is to finish to HEVC or ProRes and upload that. ProRes and DNxHR are hosted for client download rather than played in a browser. There is no codec allowlist in our code deciding what streams: what plays is decided by the viewer's browser decoder, not by a platform rule. Browser-decodable codecs stream, and 8K plays when the viewer's hardware decodes it.
Yes. Each film has an allow-download switch, and when it is on the watch page issues a signed download URL so the viewer can save the master. It is per film, so you decide title by title, and there is no tier gate on it: it works on the free plan. The one restriction is that it is forced off for a vaulted film.
Only if you asked it to. Vimeo's help center says a paid account can choose to store its source files, but the option is not on by default: you have to check the box next to Keep source video files. If the box was off, or if membership ends, Vimeo states that your source files may be deleted and may not be recoverable. Downloading from a video's page is also a paid-plan feature.
When the deliverable is a laddered platform for a mass audience, or when the client's review workflow already lives in a review tool with timecoded comments they rely on. A ladder that degrades gracefully is the right engineering for an unknown audience on unknown devices, and a review process a client already trusts is worth more than a few Mbps. Come to a no-transcode host for the finished grade, going to a small number of people who have to judge the picture.
uncompressed.io stores your master and streams those exact bytes. No transcode, no rendition ladder, no delivery ceiling, and a per-film switch that lets the client save the master itself.