Export for the eye, not for the ingest
Best export settings for client review.
Pick them for the client's decoder, not for an upload ceiling.
Almost every export preset you have been handed is really advice about surviving someone else's re-encode. Take the re-encode away and the settings question collapses into one much smaller question: what can the person watching actually decode? Here is that question answered, with the two officially published bitrate tables on the web shown for what they are.
Video hosting for filmmakers · 5 GB free · Paid plans from USD 9/month
By uncompressed.io · Updated September 2026
Why the usual advice is the wrong shape
A recommended upload setting
is a setting for the ingest.
Look at where export advice comes from. The two tables everyone quotes are published by platforms, and both are labelled for the upload step. YouTube’s is titled recommended upload encoding settings. Vimeo’s sits under compression guidelines. They describe the file at the moment you hand it over. That is a useful thing to know when you are handing a file over to be processed, and it is the wrong question entirely when nothing is going to process it.
Here the file you upload is the file that plays. The player streams the exact bytes you uploaded, and no transcode happens anywhere in the path. Nothing measures your export against an ingest target, nothing decides a rendition ladder for you, and nothing has an opinion about your bitrate. So the settings question has exactly one variable left in it: can the person you sent it to decode it.
That is a smaller question, and unlike the usual one it has published answers. Browser and platform vendors document which codecs decode where. Nobody documents what a given ingest pipeline will do to your gradient. Work from the documented side.
0
Re-encodes
The bytes served are the bytes uploaded. Your export is not an intermediate step toward some other file.
3
Codecs that stream
H.264, HEVC and AV1 play in a browser. ProRes and DNxHR are hosted here for download, not for streaming.
1
Question that matters
What does the client watch on. Every setting below follows from the answer.
The same file, two jobs
What ingests it versus
what plays it.
This is not a knock on the platform tables. They are accurate for the job they describe. The point is that they answer a question you no longer have, and an answer to the wrong question quietly becomes a ceiling you export under for no reason.

Platform figures are each vendor's own published upload recommendations, fetched 11 September 2026. YouTube's 4K and 1080p rows are the SDR standard frame rate entries; its table also publishes higher figures for high frame rate and for HDR. Vimeo's page publishes a single range per resolution and does not publish a separate HDR table.
Start here
Choose the codec first;
every other setting follows.
Codec is the only choice with a real compatibility cliff behind it. Bitrate, container and audio are recoverable mistakes. A file the client cannot open is a dead afternoon and an email you have to write.
Browser support statements are quoted from MDN's Web video codec guide, fetched 11 September 2026. MDN states browser support at the codec level; it publishes no browser-level support statement that differentiates by chroma subsampling or by bit depth.
Read the catches column again, because it is the whole decision. H.264 is the only row without a condition that lives on the client’s machine rather than yours. HEVC on Windows asks a client to buy and install an extension. AV1 in Safari asks for hardware from a specific generation. Those are not reasons never to use them. They are reasons to know the answer before you export, and to default to H.264 when you do not.
Android is worth one sentence if your client reviews on a phone. Google documents H.264 AVC Baseline decoding from Android 3.0, H.264 Main Profile from Android 6.0, HEVC from Android 5.0, and AV1 decoding from Android 10, with encoder and decoder mandatory from Android 14.
The number with no ceiling over it
Bitrate is a picture decision,
not an ingest rule.
Once nothing re-encodes, bitrate stops being a bid you place against a compressor and becomes the thing it actually is: how much data you are willing to spend on the frames you worked on, bounded by the connection the client will watch over.
The published numbers are a floor
The platform tables above are the only first-party bitrate figures on the open web. They are sized so that a file survives being processed. A review copy that is not going to be processed has no reason to sit at the bottom of that range.
The real ceiling is the connection
The file streams at the bitrate you exported it at. A client on a hotel connection watching a very high bitrate export will buffer, and that is the one failure mode worth planning around. Ask, or send a second lighter version.
Resolution follows the same logic
8K plays when the viewer's hardware decodes it, which is a hardware question on their side, not a policy question on ours. A 4K review copy is safe on far more machines than an 8K one.
Two versions is a normal answer
Versions live on the same film here, so a heavy grade-check copy and a light phone-friendly copy are not two links to keep straight. Both sit under the same film with their own comments.
The one thing to hold back
The honest limit
10-bit 4:2:2 sits outside
of what is documented.
This is the part where most guides state something confident and unsourced, so here is the verified position instead. No vendor documents 10-bit 4:2:2 HEVC decode in a video element, in either direction. The one primary decoder specification checked, Microsoft’s Media Foundation H.265 decoder, lists its chroma format as 4:2:0 chroma and does not mention 4:2:2 anywhere on the page. MDN states browser support per codec and not per chroma format. Android’s supported formats page does not mention chroma subsampling at all.
So the correct word is undocumented, not unsupported. Our side of it is settled: because we never re-encode, a 10-bit 4:2:2 file uploaded here is stored and served untouched. The browser side is not settled by anyone, and this page will not invent a result for it. For a review copy that has to play on the first click, export 4:2:0 and keep the 4:2:2 file beside it as the download for whoever needs the real thing.
The wrapper
The container is not
the codec inside it.
MDN puts the distinction plainly: a media container encapsulates one or more media streams along with metadata, and the format of a media file is defined by several components, including the codecs used and the container format. Describing a video as video/mp4 says nothing about the format of the media inside it, which is why the codecs parameter exists at all.
Practically, that means the MP4 or MOV decision is about who opens the file, not about picture quality. MDN lists MP4 browser compatibility as all browsers, and QuickTime or MOV as only older versions of Safari plus other browsers that supported Apple’s QuickTime plugin. MDN also notes that MP4 is derived from the ISO base media file format, which is itself directly derived from the QuickTime file format, while adding that the two are not quite interchangeable. Your NLE writes MOV because macOS software commonly does. Wrap the review export in MP4.
Audio is the last line and the easiest. Both published tables land in the same place: AAC at 48 kHz. YouTube publishes recommended audio bitrates of 128 kbps mono, 384 kbps stereo and 512 kbps for 5.1. Vimeo publishes AAC-LC at 320 kb/s CBR, 48 kHz. Either will be inaudible against the picture decision you just made.
The four minutes before you export
Ask one question,
then send it once.
Ask what they watch on
One line in the email: browser and machine, or phone. That answer selects the codec row above, and it is the only input the rest of the decision needs.
Set codec and container from the table
H.264 High Profile in MP4 with AAC unless the answer told you something better. 4:2:0 for anything that has to play on the first click.
Set the bitrate to the note you want back
High for a grade or a texture question, moderate for a pacing or structure question. There is no upload target to hit, so the only wrong answer is one the client's connection cannot sustain.
Upload once and share the room
The file is not re-encoded on the way in or the way out. Share the review room link, collect timecoded comments against the frames you exported, and add the next version to the same film.
What the client gets on the other end is the review room: the export playing at its own bitrate, versions of the same film in one place, comments pinned to a timecode, and captions when the film needs them. What you keep is the mastering file, hosted alongside the review copy for download by anyone who needs the actual frames rather than a look at them. See pricing for what the storage side of that costs; Starter is free with 5 GB of hot storage, and views, uploads and viewers are unlimited on every plan, including the free one.
The summary is short enough to keep. Every export preset you inherited was tuned for a step that is not in this path. Delete the ceiling from the decision and what remains is the client, their machine, and the note you are trying to get back.
Questions
Frequently asked
What is the single best export setting for client review?
There is no single one, because the constraint is the client, not the platform. H.264 High Profile in an MP4 with AAC audio is the widest-compatibility choice: MDN lists H.264 support as all versions of Chrome, Edge, Firefox, Opera and Safari, and lists MP4 browser compatibility as all browsers. Everything past that is a trade you make once you know what the client watches on.
Should I export H.264 or HEVC for a client?
H.264 when you do not know the client's setup. HEVC when you do and it is Apple hardware: MDN states Safari supports HEVC for all devices on macOS High Sierra or later. On Windows, MDN states Edge supports HEVC for devices with hardware support on Windows 10 1709 and later when the HEVC video extensions from the Microsoft Store is installed, which is a purchase and an install you cannot make on the client's behalf.
What bitrate should I export for a client review copy?
Nothing here caps it, so the ceiling is the picture and the client's connection, not an ingest rule. The only first-party numbers published anywhere are upload targets: YouTube publishes 35 to 45 Mbps for 2160p SDR at 24, 25 or 30 fps, and Vimeo publishes 30 to 60 Mbps for 4K. Treat those as a floor for a review copy rather than a target, because no re-encode is waiting on the other side to take the file apart again.
Can I just send the client the ProRes or DNxHR master?
You can host it here, and the client can download it, but it will not stream in a browser. Browser playback is H.264, HEVC and AV1. The normal shape of a review delivery is a browser-playable export for watching and commenting, with the mastering file kept alongside it for whoever needs the actual file.
Is 10-bit 4:2:2 a safe choice for a review export?
It is not documented. No vendor documents 10-bit 4:2:2 HEVC decode in a video element, in either direction, and the one primary decoder specification among the documents checked, Microsoft's Media Foundation H.265 decoder, lists 4:2:0 chroma only. Nothing here re-encodes a 4:2:2 file, so it is stored and served untouched, but whether a given browser decodes it is not something any vendor has published. For review, export 4:2:0 and keep the 4:2:2 file as the download.
MP4 or MOV for a review export?
MP4 for anything meant to be watched in a browser. MDN lists MP4 browser compatibility as all browsers, and QuickTime or MOV as only older versions of Safari plus other browsers that supported Apple's QuickTime plugin. MDN also describes QuickTime as a legacy container that is still commonly produced by macOS video recording software, which is why a MOV lands in your export folder by default without being the right wrapper to send.
Does a bigger export cost me more to share?
It costs storage, not plays. Plans have storage, seat and caption allowances; streaming has no extra charge: views, uploads and viewers are unlimited on every plan, including the free one. Starter is free with 5 GB of hot storage, and extra capacity is 40 dollars per TB hot and 20 dollars per TB cold, a month.
Send the export you actually made
Upload the file once and share a review room link. The player streams the exact bytes you uploaded, with versions, timecoded comments and captions on the same page. Start free with 5 GB of hot storage.
Sources
- 1.MDN: Web video codec guide (fetched 11 September 2026)
- 2.MDN: Media container formats (file types) (fetched 11 September 2026)
- 3.MDN: Media types and formats for image, audio, and video content (fetched 11 September 2026)
- 4.MDN: Codecs in common media types (fetched 11 September 2026)
- 5.Microsoft Learn: H.265 / HEVC Video Decoder (Media Foundation), format constraints table (fetched 11 September 2026)
- 6.Android Developers: Supported media formats (fetched 11 September 2026)
- 7.YouTube Help: Recommended upload encoding settings (fetched 11 September 2026)
- 8.Vimeo Help Center: Video and audio compression guidelines (fetched 11 September 2026)
- 9.uncompressed.io pricing: plans, storage blocks and unlimited views
