Answer
Most quality-loss questions end in guesswork, because platforms do not publish what they deliver. Audio is the exception. Vimeo lists a maximum audio bitrate for every rendition it serves, from 64 Kbps at the bottom to 256 Kbps at 4K, next to an upload recommendation of 320 kb/s. Two numbers on two of its own pages, and the gap between them is what you are hearing.
No credit card required. Cancel any time.
Updated September 2026
The short answer
Nothing degraded in transit. The file arrived intact and was then rebuilt. Vimeo puts it in one sentence: during transcoding, your video file is re-encoded into several formats that will be available to view. The audio track is part of that rebuild, and the rebuild has a published ceiling.
This is the rare quality question that does not need a measurement. Vimeo lists a maximum delivered audio bitrate for every rendition on its ladder, and the numbers are lower than the file you handed it. The 240p rendition is capped at 64 Kbps and delivered as HE-AAC V2 or Opus. The 360p rendition is capped at 129 Kbps. From 540p up through 4K the maximum is 256 Kbps, delivered as AAC or Opus. The HDR 2K and 4K renditions top out at 265 Kbps. Every conversion is resampled to 48 kHz.
Now set that beside the other page. Vimeo’s compression guidelines ask you to upload audio as AAC-LC at 320 kb/s CBR at 48 kHz. A platform that asks for 320 and delivers a maximum of 256 is re-encoding your mix downward, and it is telling you so in its own documentation. Nobody has to take a measurement or trust a benchmark. Two help-center pages, two numbers, one gap.
One qualifier that matters for honesty: Vimeo says the listed bitrates are a maximum, and that a video could transcode lower depending on the complexity of the image. So the correct reading is “up to 256 Kbps”, never “always 256 Kbps”. The ceiling is the best case.
It is worth understanding why the audio gets rebuilt at all, because the reason is not carelessness. A streaming platform does not store your file and send it out; it builds a set of renditions at different resolutions and bitrates so a player can switch between them as a connection moves. Audio travels inside those renditions. Once the platform has decided to rebuild the picture for a 240p rung that has to survive a bad mobile connection, the audio riding along with it gets a budget to match, and 64 Kbps is that budget. The audio ceiling is not a separate decision about your mix. It is a consequence of the ladder existing.
The published ceilings
Every figure below is from Vimeo. The audio maximums and the 48 kHz sample rate come from its playback-resolution guidelines; the upload recommendation comes from its compression guidelines. The video column is on the same page as the audio column and is included because it shows the whole rendition, not a cherry-picked row.
64 Kbps
the floor
the 240p rendition, delivered as HE-AAC V2 or Opus
256 Kbps
the ceiling, 540p to 4K
a published maximum, not a guarantee
320 kb/s
what Vimeo asks you to upload
AAC-LC, constant bitrate, 48 kHz
48 kHz
every conversion, resampled
whatever your master ran at
Vimeo delivers: 240p rendition
Vimeo delivers: 360p rendition
Vimeo delivers: 540p through 4K
Vimeo delivers: HDR 2K and 4K
Vimeo asks you to upload
uncompressed.io delivers
Vimeo's delivered figures are maximums per rendition, published in its playback-resolution guidelines; Vimeo states that a video may transcode lower depending on the complexity of the image. The upload figure is Vimeo's own recommended setting from its compression guidelines. The uncompressed.io bar is drawn at 320 kb/s only because that is the example track: there is no ceiling here, the delivered bitrate is whatever you exported, because the file is never re-encoded.
Vimeo's published maximums, fetched 4 September 2026. The 240p through 4K video figures are the H.264 ladder; HDR 2K and HDR 4K are the HDR and above-4K HEVC ladder from the same table. Every delivered bitrate is a ceiling: Vimeo states that a video could transcode at a lower bitrate depending on the complexity of the image. The bottom row is Vimeo's recommended upload setting from a different help page, and it is deliberately higher than anything in the rows above it.
The video column is worth a glance even on an audio page, because it tells you how much the ladder is doing. Vimeo markets a ceiling of 4K Ultra HD, and that ceiling arrives at up to 22 Mbps. The rendition that carries 256 Kbps of audio is the same rendition carrying 22 Mbps of picture. The one that carries 64 Kbps of audio is carrying 0.3 Mbps of picture. The audio ladder and the video ladder fall together, which is why a viewer who complains that the picture looks soft usually has a thin-sounding mix as well.
The sample rate deserves a line of its own. Vimeo states that the audio sample rate for all conversions is 48 kHz. For most film and television work that changes nothing, because 48 kHz is already the delivery standard. It does matter if your mix came out of a music session at 44.1 kHz, or at 96 kHz from a sound-design session: that track is resampled on the way through, and a resample is a processing step you did not sign off on. Print the delivery at 48 kHz yourself and the conversion becomes a no-op instead of a surprise.
The consequence you hear
You do not choose the rendition. The player does, from the viewer’s screen, their connection and what your upload made available. That choice sets the audio bitrate, so the same delivery can reach one client at 256 Kbps and another at 64.
Vimeo gates the top of the ladder on the uploaded dimensions: a 4K rendition exists only if the larger dimension is at least 3,648 pixels or the smaller is at least 2,052; 2K needs 2,432 or 1,368; 1080p60 needs 1,824 or 1,026. Below those thresholds the rendition is never built, so the audio bitrate attached to it is never available either. Above them it exists, but the player still has to choose it.
A mix that survives 256 Kbps can come apart at 64. That is not a subtle difference, and it is not distributed evenly across the mix. Some material is nearly immune and some falls over first.
This is also why the note that comes back from a client so often makes no sense to the person who mixed it. You approved the film on a fast connection, on the top rendition, at 256 Kbps. Your client opened the link on a laptop tethered to a phone, the player settled on a low rung, and the track they heard was a different encode of a different bitrate. Two people described the same file honestly and disagreed, because they were not listening to the same file. Nothing in the interface tells either of them which rendition they got.
The first casualty, every time. A perceptual encoder spends its bits on what is loud and obvious, and a decaying tail is neither. Tails get truncated and grainy, rooms go flat, and a scene that felt like a space starts to feel like a booth. Sound designers notice this before anyone mentions a number.
Low-bitrate encoders lean hard on joint stereo, coding the sum and the difference and starving the difference channel. Wide pads, stereo ambiences and hard-panned effects collapse toward the centre. A mix that was carefully placed left to right arrives narrower than it left.
High-frequency noise is expensive to encode and cheap to approximate, so it gets approximated. Hats and rides turn watery and swirl, esses on a voiceover start to smear, and sharp transients pick up a faint ring in front of them. At 64 Kbps many encoders simply stop reproducing the top octave and fill it in.
Everything you placed 20 or 30 dB under the voice to make a scene feel alive is exactly what a starved encoder discards first, because it is masked. The dialogue survives and the world around it quietly disappears. The client hears a video that sounds cheaper without being able to say which element is missing.
A full band, a busy orchestral cue or anything with sustained cymbals gives the encoder no easy places to save bits, so the artefacts spread across the whole track rather than hiding in one element. This is why a talking-head interview survives compression far better than a music-led brand film.
Centred, mid-range, dry dialogue. Clean voiceover on a quiet bed. If your delivery is a corporate interview cut, the rendition ladder will barely bother you. If it is a piece where the sound design is the work, it will.
What to do on any platform
None of this removes the ceiling. It stops you from adding your own losses on top of the platform’s, which is the part that is actually in your hands.
On Vimeo that is AAC-LC at 320 kb/s CBR at 48 kHz, which is its published recommendation. Uploading at the recommended setting does not raise the delivered ceiling, but it hands the transcoder a clean source, so the one lossy generation you cannot avoid starts from the best possible input.
Encoding a lossy file into another lossy file compounds the damage: the second encoder faithfully reproduces the first encoder's artefacts and then adds its own. Go back to the uncompressed or lossless mix and export once, straight to the delivery file. A bounce that has been through a shared drive, a messaging app or a previous upload is not a master.
Pick where loudness is set and set it once, in the mix. Running a normalisation pass over an already-normalised export shifts levels a second time and can push peaks into limiting you never approved. Print the mix at the loudness you intend to deliver and leave it alone after that.
Not the top one. Open the delivery on a phone on mobile data, and on the screen your client actually uses, and listen for the tails and the low-level layers. If the mix only holds together at the highest rendition, it will not survive the ladder, and finding that out before delivery is cheaper than finding out after.
A caution about numbers you find elsewhere
The structural answer
Every fix above works inside the constraint. The constraint itself is a rendition ladder, and the only way past it is a host that does not build one.
Here, the player streams the exact bytes you uploaded. The audio track plays as exported: no AAC or Opus re-encode, no resample away from your sample rate, no loudness pass, because nothing is transcoded at any point in the path. There is one file, the one you made, and every viewer gets it. Uploads are MP4 or MOV carrying H.264, HEVC or AV1, up to 50 GB per file. What you approved in the mix room is what arrives.
The practical effect on a sound approval is that the conversation stops being about the platform. When a composer, a sound designer and a director all open the same link and hear the same bytes, a note about a reverb tail is a note about the mix, and it can be answered in the review room against a timecode instead of being argued about for a week. Nobody has to ask which rendition the other person got, because there is only one. That is a smaller claim than it sounds: it does not make the mix better, it just removes a variable that had no business being in the room.

Vimeo figures from its published playback-resolution guidelines, fetched 4 September 2026. The uncompressed.io column describes streaming the uploaded file without transcoding; uploads are MP4 or MOV carrying H.264, HEVC or AV1, up to 50 GB per file.
The same reasoning applies to the picture, and the mechanism is identical: one file, delivered whole, instead of a set of rebuilt approximations. If the visual side is the part that bothers you, the longer version of that argument is in video hosting that does not compress and in why your video looks worse after upload.
When you should stay on the ladder
The rendition ladder is not a mistake. It is an engineering answer to a real problem, and on the wrong project, removing it makes things worse rather than better.
If your delivery target is a broad public audience watching on phones, on mobile data, in transit, on hardware you will never see, then a ladder that includes a 64 Kbps rendition is what keeps the video playing at all. A thin-sounding track that plays is worth more than a perfect track that stalls. That is the whole design intent of adaptive delivery, and it works.
There is no ladder here, and that trade runs both ways. A viewer on a poor connection buffers instead of silently dropping to a low rendition, which is the right behaviour for a client reviewing a grade and the wrong behaviour for a marketing video aimed at everyone. Playback also depends on the viewer’s machine having a hardware decoder for the codec you uploaded, which is a safe assumption for a post house and a shakier one for the general public.
So the split is straightforward. Public reach, phones and unknown devices: use a platform with a ladder, accept the audio ceiling, and mix so the important material survives 64 Kbps. Client review, grade approval, sound-design approval, festival and portfolio delivery, anywhere the point is that someone hears the work as it was finished: send the file itself. Vimeo’s player, marketing tools and OTT products have no equivalent here, and if those are what you are paying for, this page is not asking you to leave.
The one-line version
Questions
Because the platform re-encoded it. Vimeo states plainly that during transcoding your file is re-encoded into several formats, and its playback-resolution guidelines list the audio ceiling for each of those formats: a maximum of 64 Kbps on the 240p rendition, 129 Kbps at 360p, 256 Kbps from 540p through 4K, and 265 Kbps on the HDR 2K and 4K renditions. Every conversion is resampled to 48 kHz. Your master was not what your viewer heard.
Both figures come from Vimeo's own help center and they are answering different questions. The 320 kb/s CBR AAC-LC recommendation is what Vimeo wants you to hand it, so the encoder starts from a clean source. The 64 to 265 Kbps table is what Vimeo hands your viewer. A platform that asks for 320 and publishes a ceiling of 256 is telling you, in its own documentation, that it re-encodes your mix downward.
Whichever one the player picks for their screen and connection, and that choice decides the audio bitrate. Vimeo gates the higher renditions on the uploaded dimensions, so a 4K rendition only exists if the larger dimension is at least 3,648 pixels. A viewer the player puts on 240p is hearing a 64 Kbps track no matter how good your master was. That is why a mix should be checked on the rendition a client will realistically land on, not on the top one.
It stops you from stacking a second generation of loss on top of the platform's, which is worth doing, but it does not raise the ceiling. Upload the cleanest source the platform will take, in Vimeo's case AAC-LC at 320 kb/s CBR at 48 kHz, and the delivered track is still capped by the rendition table. The only thing that removes the cap is a host that does not re-encode.
Nothing. The player streams the exact bytes you uploaded, so the audio track plays as exported: no AAC or Opus re-encode, no resample, no loudness pass, because nothing is transcoded at any point. Uploads are MP4 or MOV carrying H.264, HEVC or AV1, up to 50 GB per file.
There is no low rendition to fall back to. A viewer on a poor connection buffers instead of silently dropping to a mushy 64 Kbps version, and playback depends on their machine having a hardware decoder for the codec you uploaded. If your audience is a broad public on phones and mobile data, that trade goes the other way and a ladder is the right tool.
uncompressed.io streams the exact bytes you upload. The audio track your viewer hears is the audio track you exported, at the bitrate you exported it, with no second encode.