No platform ceiling below your file
Streaming a 200 Mbps file in a browser.
The arithmetic, and the two ceilings that are actually real.
Every consumer platform re-encodes your upload down to a delivery ladder, so the bitrate a viewer receives is the platform's number, not yours. Here nothing re-encodes, so a 200 Mbps master is delivered at 200 Mbps. That shifts the limit onto two things we do not control: the viewer's connection and the viewer's decoder. This page does the arithmetic on both.
No credit card required. Cancel any time.
Updated September 2026
Start with the numbers
What 200 Mbps actually
is asking of a viewer.
Bitrate is a rate, so everything else follows from it by division. None of the figures in this table are measurements of anything. They are arithmetic on the bitrate itself, which is why they are true for any file at that rate, on any platform, from any camera.
Arithmetic, not measurements: bits divided by eight for bytes, multiplied by the runtime in seconds, in decimal gigabytes. The 22 Mbps column is there for scale: it is the maximum video bitrate Vimeo publishes for a 4K rendition on its standard H.264 delivery ladder, and Vimeo states that the bitrates listed for each resolution are a maximum, so a real delivery can be lower. Our 50 GB row is our own per-file ceiling.
Two things fall out of that table immediately. The first is that 200 Mbps is about nine times the highest 4K bitrate Vimeo publishes for delivery, and about twenty-eight times its published 1080p60 maximum of 7 Mbps. The second is that a 200 Mbps hour is 90 GB, and our per-file ceiling is 50 GB, so at that bitrate one file holds roughly half an hour. Nobody tells you the second number, so plan the export around it rather than discovering it at the drop.
25 MB/s
Sustained, for a 200 Mbps stream
The viewer's connection has to hold this for the whole runtime, not peak at it once.
90 GB
One hour at 200 Mbps
Arithmetic from the bitrate. The same hour at Vimeo's published 4K maximum is about 9.9 GB.
50 GB
Our per-file ceiling
About 33 minutes at 200 Mbps. Checked in the browser before an upload starts.
Where the ceiling normally comes from
A file we never re-encode
is not a delivery ladder.
On a consumer platform, the number a viewer receives was decided by the platform, not by you. Your upload is re-encoded into a set of delivery formats, and the player picks one of them. Vimeo documents that process plainly, and publishes the ceiling of each rung.
Vimeo figures from its own help center and pricing page, fetched 5 September 2026. Our per-file ceiling of 50 GB is checked in the browser before an upload begins. The last row is the honest trade in both directions: a delivery ladder is what lets a platform hide a bad connection, and refusing to build one is what lets a 200 Mbps file arrive intact.
The gap is visible in Vimeo’s own documentation. It recommends uploading 4K at 30 to 60 Mbps, and it publishes a 4K delivery maximum of 22 Mbps. Both numbers are correct and both are theirs. The distance between them is the ladder doing its job, and it is the distance a 200 Mbps master never crosses here.
The mechanism on our side is unglamorous. The player is a plain video element pointed at a short-lived link to the stored master. There is no ladder, no manifest, no rendition set, and no encode step between the upload finishing and the file being playable. That is the whole reason a 200 Mbps file is delivered at 200 Mbps: not because we did something clever with delivery, but because we did nothing to the file at all.
It also means there is nothing to fall back to. A platform with a ladder can hand a struggling viewer a 2.5 Mbps copy and call it playback. We cannot, so a viewer whose connection cannot hold the rate sees a buffer instead of a quiet drop in quality. For a client reviewing a grade, that is usually the right failure: buffering is visible, and a silently downgraded image is not.
The honest engineering note
Two ceilings are real,
and they are both the viewer’s.
Removing the platform ceiling does not remove every ceiling. It moves the limit onto the viewer’s side of the wire, where neither of us controls it. There are exactly two things there, and it is worth being precise about both.
The connection has to hold the rate
A 200 Mbps stream needs about 25 megabytes per second sustained for the entire runtime. A speed test measures a peak on an idle line; a review session competes with everything else in the building. This is the ceiling that bites most often, and it is the one you can actually ask about before a screening.
The machine has to decode the file
Real-time decode is work, and how much work depends on the codec, the resolution, the frame rate and the chip doing it. A laptop that plays a 4K HEVC file without effort may not do the same at 8K. This is a property of the viewer's hardware, not of the hosting.
Nobody publishes a number for the second one
There is no vendor document stating a browser decoder bitrate ceiling that you could design around, in either direction. We are not going to invent one, and you should be suspicious of any page that quotes one without a source. What exists is your file and their machine.
Which is why you test it
Send the actual file to the actual reviewer on the actual machine they will use, before the deadline. One test answers both questions at once, and it answers them for the only configuration that matters. Everything else is a guess dressed up as a specification.
The one rule we hold to
Getting the file up there
A 15 GB drop, held
over a long upload.
A ten-minute film at 200 Mbps is 15 GB. That is a long enough transfer that the interesting question is not how fast it starts but what happens when the line dies in the middle of it.
Check the runtime against 50 GB first
50 GB is the per-file ceiling, which at 200 Mbps is about 33 minutes of runtime. The browser checks the size before the transfer starts, so an oversized file is refused immediately rather than after an hour. Being straight about it: that check runs in the browser, not on the server.
It goes up in 10 MB parts
The file is cut into 10 MB parts and sent in parallel. Small parts are the reason a failure costs seconds rather than the whole transfer: a part that dies is a part that gets retried, not a file that starts over.
The lanes adapt to your line
Three parallel lanes to start, a ceiling of six. The count halves when a part fails and gains a lane after eight clean parts in a row. The per-part timeout moves with measured throughput rather than sitting at a fixed number, so a slow hotel line is treated as slow rather than as broken.
A dead line gets 60 attempts per part
Each part is retried up to sixty times, which is roughly three quarters of an hour of a dead connection before the uploader gives up on it. Moving around inside the app does not interrupt any of this; the uploader lives above the page.
What does not survive
When this is the wrong tool
Three cases where
you should stay on Vimeo.
Full-bitrate delivery is the right answer for a small, known audience on good machines: a director, a colorist, an agency reviewer, a festival programmer, a client signing off a grade. It is the wrong answer for a large anonymous public, and pretending otherwise would make this page useless.
Stay on a laddered platform if your viewers are on phones and mobile networks. A ladder exists precisely to serve a viewer whose connection you cannot predict, and Vimeo publishes rungs from 240p at 0.3 Mbps upward for exactly that reason. Stay if the piece is a marketing video meant for thousands of strangers, where the goal is that it plays everywhere rather than that it plays perfectly. And stay if your file is longer than the arithmetic allows: Vimeo accepts up to 300 GB and 24 hours per file regardless of plan, and our ceiling is 50 GB.
The trade runs the other way for the review copy. Vimeo caps self-serve bandwidth at 2 TB a month, and a 90 GB file consumes that allowance quickly, which is one more reason its ladder exists. Nothing is metered here except storage, so the same file can be played as many times as the work needs. Pick per file rather than per platform: the master goes where nothing touches it, and the public cut can live wherever it reaches the most people.
Questions
Frequently asked
Can a browser really play a 200 Mbps file?
It depends on the viewer's machine and connection, not on us. Our side never re-encodes, so the file offered to the browser is the file you uploaded, at its own bitrate. Whether that browser decodes it in real time is decided by the viewer's hardware and the codec and resolution of the file. No vendor publishes a decoder bitrate ceiling you can rely on, so the only honest answer is to test the actual file on the client's actual machine before you promise anything.
What connection does a viewer need for a 200 Mbps stream?
One that holds about 25 megabytes per second for the whole runtime, which is 200 megabits per second sustained. Peak speed on a test site is not the same thing as sustained throughput over an hour on shared home Wi-Fi. If the viewer cannot hold that rate, the player buffers, because there is no lower rendition to switch down to. That is the honest trade for never re-encoding.
How big is an hour of 200 Mbps footage?
About 90 GB. That is arithmetic from the bitrate, not a measurement: 200 megabits per second across 3,600 seconds is 720,000 megabits, which is 90,000 megabytes. Our per-file ceiling is 50 GB, so at 200 Mbps a single file tops out at roughly 33 minutes of runtime. Longer pieces go up as reels or parts, or at a lower bitrate.
Is there a bitrate cap on the free plan?
No. There is no bitrate cap on any plan, because there is no encoder in the path to impose one. The free Starter plan gets 5 GB of storage and one film at a time; what it does not get is a lower delivery ceiling. Bandwidth is not metered on any plan, and the player carries no platform logo or watermark on any plan.
Why does the player buffer instead of dropping to a lower quality?
Because no lower quality exists. There is no adaptive ladder here and no transcode step, so there is exactly one file: yours. A platform that builds a ladder can quietly hand a viewer a mushy 2.5 Mbps rendition when the line dips. We cannot, and we would rather you know that up front than discover it in a client review.
Does the upload survive if I close the laptop?
No. The uploader survives moving around inside the app, because it is mounted above the page. It does not survive a reload or a closed laptop: the browser has discarded the bytes. What survives is the progress record, so the resume banner lists the interrupted file and you drop the same file in again to continue from the last finished part rather than from zero.
Should I upload a ProRes master to stream at high bitrate?
No. Camera RAW never streams at all, and ProRes and DNxHR are hosted for client download rather than played in a browser. For a high-bitrate stream, export the finished film to HEVC or H.264 at the bitrate you want delivered, then upload that. It arrives at exactly the bitrate you exported.
Send the master, not a compressed copy of it
The player streams the exact bytes you upload, with no transcode step anywhere and no metered bandwidth. Storage is the only meter, on every plan including the free one.
Sources
- 1.uncompressed.io pricing: plans, storage, unlimited views, uploads and viewers (fetched 5 September 2026)
- 2.uncompressed.io Terms: storage is the only meter, no bandwidth caps (fetched 5 September 2026)
- 3.Vimeo Help Center: guidelines for determining playback resolution, delivery bitrate maximums per rendition (fetched 5 September 2026)
- 4.Vimeo Help Center: recommended compression settings for upload (fetched 5 September 2026)
- 5.Vimeo Help Center: what happens during transcoding (fetched 5 September 2026)
- 6.Vimeo Help Center: playback above 4K, HEVC delivery and device exclusions (fetched 5 September 2026)
- 7.Vimeo Help Center: monthly bandwidth threshold on self-serve accounts (fetched 5 September 2026)
- 8.Vimeo pricing page: per-file size and duration limits, storage per plan (fetched 5 September 2026)