Why does Vimeo compress my video so much?
Because every upload is re-encoded into a ladder of renditions.

Read that sentence carefully, because it contains the whole mechanism. Not one format, several. Not stored, re-encoded. What you uploaded becomes the input to a batch of new files, and one of those new files is what a viewer’s browser requests when they press play. Your master, whatever bitrate it left your timeline at, is never the thing being streamed.

It is worth saying that Vimeo is not hiding this and is not being stingy. The same help article notes that the file size on Vimeo can sometimes end up larger than the uploaded file, which it attributes to a focus on preserving video quality. A platform trying to save money on your footage does not produce bigger files than it received. The compression has a different cause, and the cause is architectural.

Below those, the ladder continues down through 720p at up to 2.5 Mbps, 540p at up to 1.5 Mbps, 360p at up to 0.5 Mbps and 240p at up to 0.3 Mbps. The full table, both ladders side by side, lives on the page about Vimeo’s 4K streaming bitrate, which is where to go if you want the numbers rather than the mechanism.

Now put the delivery ceiling next to the upload advice, because the two come from the same help center. Vimeo’s compression guidelines recommend uploading 4K at 30 to 60 Mbps, 2K at 20 to 30, 1080p at 10 to 20 and 8K at 50 to 80. The platform asks for a large file and then delivers a much smaller one. That is not a contradiction; a clean, high-bitrate source produces a better transcode. But it does mean most of what you upload is spent at conversion, by design, on every plan.

A modern encoder does not send a full picture every frame. It sends a complete image occasionally and, in between, sends only what changed, plus predictions built from the frames around it. When very little changes, those predictions are cheap and accurate, and the encoder finishes well under its ceiling with the picture intact. When almost every pixel changes every frame, the predictions fail and the encoder has to spend real bits on real detail, until it hits the ceiling and starts discarding.

That is why the failure is never uniform across a film. Dialogue on a clean background comes back looking close to your master. Film grain, rain, smoke, water, foliage, confetti, a handheld whip pan and a slow fade through near-black are all expensive by exactly this mechanism, and they are the first things to go. If the symptom is what brought you here, the page on why Vimeo videos look worse than your export takes it apart shot type by shot type. If the underlying encoding concepts are new, start with what video compression actually is.

This matters most to people who do not deliver in plain 16:9. A 2.39:1 scope crop, a vertical cut for social, a square export or any letterboxed master can sit below a threshold you assumed you had cleared, and the top rendition is then never built at all. The viewer is not choosing a lower rung; the rung does not exist. Checking the actual pixel dimensions of your export against the numbers above takes a minute and prevents the most avoidable version of this complaint.

Above 4K the gate is stricter still. Vimeo states it will only generate a 5K to 8K transcode if the creator uploaded the file as an HDR video greater than 5K resolution, and that anything beyond 4K is delivered in HEVC with the device restrictions listed earlier. Vimeo’s own marketing on its pricing page sets the general expectation at streaming up to 4K Ultra HD.

The video side gets all the attention, but the audio track goes through the identical process and the numbers are just as public. Vimeo’s compression guidelines recommend uploading audio as AAC-LC at 320 kb/s constant bitrate with a 48 kHz sample rate. Its playback specifications then set the delivered maximum at 256 Kbps for every rendition from 540p through 4K, using AAC and Opus, and state that the audio sample rate for all conversions is 48 kHz.

Lower down the ladder it thins out considerably: a maximum of 129 Kbps at 360p, and a maximum of 64 Kbps at 240p using HE-AAC V2 and Opus. A viewer whose connection drops the player to a low rung is not only watching a softer picture, they are hearing a different mix. For dialogue that is usually survivable. For a music video, a sound-design showcase or anything a composer is being asked to sign off on, it is not.

Everything above is advice for improving the input to a process that will still run. The structural alternative is to remove the process. uncompressed.io stores the file you upload and the player streams those exact bytes: no transcode, no rendition ladder, no re-encode of video or audio anywhere in the path. There is no delivery ceiling to publish here because there is no delivery encoder. A 150 Mbps export plays at 150 Mbps.

The practical shape of that: MP4 or MOV in H.264, HEVC or AV1, up to 50 GB per file. A 10-bit 4:2:2 HEVC file is stored and served untouched like any other, though whether a given browser decodes 4:2:2 is not documented by any vendor, in either direction. ProRes 422, ProRes 4444 and DNxHR are hosted for client download rather than streamed, because no browser decodes them, and camera RAW is never uploaded raw or streamed at all; the honest workflow there is to finish to HEVC or ProRes and then upload. No bandwidth is metered on any plan, including the free one. Storage is the only meter.

And the honest cost, stated plainly, because this page would be worthless without it: with no ladder there is no lower rung to fall back to. A viewer on a poor connection buffers instead of silently dropping to a mushy rendition. Playback also depends on that viewer’s hardware decoder, which is a real constraint on very high bitrate or 8K files and not a footnote. Vimeo made the opposite trade deliberately, and for a large audience it is the right one.