Client delivery
Deliver social cutdowns to a client:
every cut streams at the bitrate you exported it at.
A social package is not one film with options. It is a list of exports you rendered one at a time, and each one deserves to be judged as the file you made. Here is what a real package contains, where quality is actually lost between your timeline and a published post, and the one part of that chain a host can honestly promise to leave alone.
Video hosting for filmmakers · 5 GB free · Paid plans from USD 9/month
Updated September 2026
What is actually in the package
A social cutdown package is a list of exports,
not a film with settings.
The word cutdown makes it sound like one film gets shorter. On a real job it is a render queue. Each item leaves your timeline as its own file, with its own encode, and it should arrive with the client as its own file too.
The hero cut
The full film the campaign was built around, at the highest data rate anything in the package will carry. It is the one that goes on the site, in the deck and on the channel where the client controls the page. If one file in the package is going to be judged on the grade, it is this one.
The duration cuts
Sixty, thirty, fifteen. These are not trims of the hero; they are separate timelines with their own pacing, their own music edit and their own end frames. Each one is a render, and each one collects its own round of notes, because a note about the 15 is almost never a note about the 60.
The placement variants
A vertical render for a feed watched on a phone. A pass with captions burned in for silent autoplay. A version with the end card removed because the platform draws its own over the last two seconds. Every placement rule the client's media plan carries turns into one more file in your queue.
The one thing they share
Nothing, technically. Different lengths, different framings, different bitrates, different approvals. What they have in common is that somebody has to say yes to each one before it is scheduled, and that is the job the delivery has to support.
The practical rule is simple. A different edit is a different film, with its own link, its own notes and its own approval. A revision of the same edit is a version stacked on that film, which keeps the earlier cut and the notes written against it. Get that split right at the start of the round and the second round does not inherit the first round’s comments. The review and approval guide covers the mechanics of that in more detail.
The compression argument
The review copy is the export, because
nothing is re-encoded on the way in or out.
This is the part of the chain we can actually promise something about, so it is worth being precise. The player streams the exact bytes uploaded. There is no encode at upload, no encode at playback and no second smaller rendition sitting behind the first.
The consequence for a cutdown package is direct. A 15-second vertical exported at 40 Mbps plays at 40 Mbps. The hero at 80 Mbps plays at 80. Neither one is normalised down to a house ceiling, and neither one is quietly re-encoded because it was the smaller file in the batch. Whatever difference the client sees between two cuts is a difference you put there in the export.
That cuts both ways, and the second half is the useful half. If a client watches the vertical cut and says it looks soft, that is information about your export rather than about the platform hosting it. Fast motion in a short cut eats bitrate that a slow hero never needed. A grainy night sequence at the same data rate as a daylight interview falls apart first. When there is no transcode in between, the complaint points straight back at the render setting, which is the only place you can fix it anyway.
The honest cost of a single rendition is buffering. There is no smaller version to fall back to on a weak connection, because a smaller version was never made. If the person approving will watch on a phone in a car park, send a lighter export for that round.
0
Re-encodes on our side
No transcode at upload, none at playback, and no second rendition
5 TB
Largest single file
Resumable: an interrupted upload continues rather than restarting
0
Bandwidth metered
Storage is the only meter, on every plan including the free one
1
Link for the round
The share link is the authentication; the client makes no account and uses no seat
Where quality actually goes
Four stages between your timeline and the post,
and a host controls exactly one of them.
Every conversation about social delivery quality gets confused because four different things are being called compression at once. Separate them and the argument becomes answerable. Here is the whole chain, including the columns nobody selling you a host has any influence over.
Read the second column as the only one a host can make a promise about, and read the fourth as the one that decides what the public sees. Choosing a host that does not re-encode removes one loss from the chain; it does not remove the others, and any page that suggests otherwise is selling you something.
The point of laying it out this way is not to win the second column. It is to stop the second column from being blamed for the fourth. When the review copy and the export are the same file, a disagreement about the picture has exactly two possible homes: your render settings, or the publishing platform’s encoder. Both are diagnosable. Neither is a mystery about hosting.
Export targets
YouTube publishes its upload bitrates,
so export each cut against them.
If you need a defensible number to put in a deliverables spec, start with the one the destination publishes itself. YouTube lists recommended upload bitrates by resolution, dynamic range and frame rate. Treat them as the floor for anything headed there, and as a reasonable reference point for cuts headed elsewhere.
YouTube's recommended upload bitrates for video, fetched 8 September 2026. These are upload recommendations, not the bitrates YouTube serves after it re-encodes. Other platforms do not publish an equivalent table, so a spec that quotes these numbers is quoting the only public target in the set.
Two things follow from that table. The first is that a single house preset is the wrong tool for a package with a 4K hero and a set of 1080p placement cuts. The numbers move by a factor of four across the rows, and the high-frame-rate column moves again on top of that. The second is that these are upload numbers. They describe what YouTube wants to receive, not what it will send to a viewer, and the gap between those two is the whole reason the last column of the previous table exists. There is more on that in the YouTube 4K bitrate guide.
For the review copy itself, export above the target rather than at it. Nothing re-encodes it here, so the only thing that data rate has to survive is a person deciding whether the grade is right.
The handover
Switch on original-file downloads and
the review link becomes the delivery.
The last mile of a social package is usually where the workflow breaks: the review happened in one place, the files arrive from another, and a week later nobody can say which link held the approved version. It does not have to be two places.
Put each cut up as its own film
The hero, each duration cut and each placement variant go up separately, so each one carries its own link, its own timecoded notes and its own approval. A revision of any one of them stacks as a version on that film rather than replacing it, so the earlier cut and its notes stay where the client left them.
Send one link per cut, no accounts
The share link is itself the authentication. The client needs no account, no password and no invitation, and never consumes a seat. Approval is recorded per version, by name, and posting a new note on an approved cut revokes that approval, which is what keeps the record honest when a round reopens.
Turn on original-file downloads
Once a cut is signed off, the owner switches on original-file downloads for that film. The client then pulls the exact export from the same page they reviewed on. No second tool, no second upload, no transfer link that expires while they are on holiday.
Let them download it as often as they want
Bandwidth is not metered, so a media buyer who pulls the whole package four times across three agencies costs nothing extra. Storage is the only meter, which means the size of the package decides the plan and nothing else does.
One detail worth telling the client in writing
Read this before you promise anything
The publishing platform’s encoder
is the last word.
If the client publishes straight to a social platform, that platform re-encodes the file, and no host changes that. Not this one, not any other. A review copy that streams at the bitrate you exported it at is a real thing and it settles a real argument, but it settles the argument about your work, not the argument about what a phone in someone else’s feed will show.
That is worth saying to the client before the campaign runs rather than after. The review copy and the published post will not look identical, the published post will usually look worse, and the reason is an encoder tuned for delivery at scale on connections nobody controls. An editor who has explained that in advance is having a technical conversation. An editor explaining it after the client has already seen the post is having a different one.
There is one case where none of this applies and it is worth knowing. If the client is embedding the cut on their own site, or presenting it in a room, or handing it to a broadcaster, there is no social encoder in the chain at all and the file they publish is the file you exported. That is the case where an uncompressed review-and-delivery link is doing the whole job rather than half of it, and it is the case worth pricing for.
What this page is not claiming
Questions
Frequently asked
How many files is a social cutdown package, really?
On most campaigns it is between four and a dozen. There is the hero cut, two or three duration cuts, and then the variants a specific placement forces: a vertical render, a version with captions burned in for silent autoplay, a version with the end card stripped because the platform draws its own. Each of those is a separate render out of your timeline, so treat each one as its own deliverable with its own approval rather than as a setting on the hero.
Should each cutdown be its own upload or a version of the hero?
Its own film when it is a different edit, a version when it is a revision of the same edit. A 15-second cut is a different film from the 90-second hero: different notes, different approval, its own link. A second pass on that same 15-second cut is a version stacked on it, which keeps the earlier cut and its notes intact. Getting this right is what stops a note written against one cut from resurfacing on another.
My client says the vertical cut looks softer than the hero. What is going on?
Look at your export before you look at anything else. The player streams the exact bytes uploaded, with no transcode on the way in and none on the way out, so the file the client is watching is the file you rendered. A short cut full of fast motion at the same data rate as a slow hero will fall apart first. Raise the bitrate on that specific export and send it again.
Does uploading a high-bitrate master stop Instagram or YouTube compressing it?
No. Every publishing platform re-encodes on upload and there is no host, setting or file that changes that. What a high-bitrate upload does is give their encoder a clean source to work from, which is why YouTube publishes recommended upload bitrates at all. Tell your client this before the campaign runs, because the difference between the review copy and the published post is otherwise blamed on the edit.
How does the client actually get the files?
Switch on original-file downloads for the film and the client pulls the exact export from the same link they reviewed on. There is no second tool, no second upload and no separate transfer link to chase. Bandwidth is not metered, so a client downloading the same package four times costs nothing extra.
Is there a file size limit on a long hero cut?
Uploads run to 5 TB per file and they are resumable, so an interrupted transfer picks up where it stopped instead of starting over. In practice a social package is nowhere near that; the ceiling matters for the master you keep alongside it. Browsers play H.264, HEVC and AV1, so a ProRes or DNxHR master is hosted for download rather than streamed.
Do I need a new link when a cutdown changes?
No. Upload the new cut against the same film and the link, the id, the view count, every embed and the player and review settings all survive. Only the media changes. That matters on a social package because the link is often already pasted into a brief, a channel or a calendar invite by the time round two lands.
Send the cutdowns as the files you exported
Every cut streams at its own data rate, because nothing is re-encoded on the way in or on the way out. Storage is the only meter, so the size of the package is the only thing that decides the plan.
Sources
- 1.YouTube Help: recommended upload encoding settings (recommended video bitrates for SDR and HDR uploads at 1080p and 2160p, standard and high frame rate; fetched 8 September 2026)
- 2.uncompressed.io pricing: plans, storage and unmetered viewing (storage is the only meter; views, viewers and uploads are not metered; verified 8 September 2026)
- 3.uncompressed.io: the client review room (share-link access, versions per film, timecoded notes, owner-enabled original-file downloads; verified in product code, 8 September 2026)