Client handoff
How to deliver DNxHR files to clients.
One handoff, two jobs.
A DNxHR master is a finishing file, and finishing files do not play in a web page. The workflow that actually holds a deadline is a streamable review cut for the approval, and the DNxHR master hosted for download beside it, handed over together.
Video hosting for filmmakers · 5 GB free · Paid plans from USD 9/month
By uncompressed.io · Updated September 2026
Start from what the file is for
DNxHR is a finishing format.
It was never a viewing format.
Nobody exports DNxHR so that a client can watch it. It is exported so an assistant can conform it, a colourist can grade it, an archive can hold it, or a broadcaster can accept it. Then, at the end of the week, somebody has to email it to a client, and the workflow falls over.
It falls over for a structural reason, not a configuration one. Here, browser playback is H.264, HEVC and AV1. ProRes 422, ProRes 4444 and DNxHR are hosted for client download, not streamed. So a DNxHR master in a web page is a file waiting to be fetched, and approval does not wait for a fetch to finish.
The honest answer is to stop asking one file to do two jobs. Export a review cut in a codec browsers decode, put it and the DNxHR master in the same library, and hand both over as one delivery. The client presses play on the review cut this afternoon. The person who actually needs the bytes downloads the master whenever their schedule allows. No re-encode happens to either one at any point.
If the deliverable is ProRes rather than DNxHR, the same two-file shape applies and the host comparison lives on the ProRes client delivery guide. What follows is the part that is specific to sending a master nobody can stream.
H.264, HEVC, AV1
What streams here
Browser-decodable codecs stream. A DNxHR master is hosted for client download instead.
Exact bytes
What the player sends
The player streams the bytes you uploaded. There is no transcode anywhere in the path.
5 GB free
Starter
One film at a time, no credit card. Enough to test the review cut before anything is billed.
The workflow
Two exports,
one delivery.
Decide what each file is before you export either one, and the handoff stops being a negotiation with the client about why the file will not open.
Export the master to the spec, not to a habit
Read the deliverable spec and export the DNxHR flavour it names, in the wrapper it names. If no spec exists, ask the person who will conform the file which one they want rather than guessing from what your project happened to be set to. A master exported to the wrong flavour is a re-export, not a note.
Export a review cut from the same locked timeline
Same grade, same frames, same audio, different codec. H.264, HEVC or AV1 in an MP4 wrapper. MDN lists MP4 as supported by all browsers and describes QuickTime as a legacy container, so MP4 is the safer wrapper for the copy a stranger will open.
Upload both, and let the review cut carry the conversation
The master and the review cut live in the same library. Versions, timecoded comments, review rooms and deliverables all attach to the file people are actually watching, which is the review cut. The master sits there unaltered, waiting for the one person who needs it.
Hand over the master when the cut is approved
Downloading a finishing master before the picture is locked wastes everyone a night. Once the review cut is signed off, the same handoff gives the downstream team the DNxHR file, byte for byte as you exported it.
Why not just send the master and let them figure it out
Choosing the review-cut codec
Pick for the browser your client uses,
not what yours does.
The master is decided by the deliverable spec. The review cut is decided by whoever is going to press play, and that person is usually not a filmmaker. The table is MDN in its own words.
Quoted from MDN's Web video codec guide, fetched 11 September 2026, which describes decode in a video element. DNxHR is outside this picture entirely: it is hosted here for client download rather than browser playback.
Read the AV1 row before you reach for AV1. It is supported everywhere, but on Safari that support is limited to devices with a hardware decoder, which MDN names as M3 MacBooks and later, iPhone 15 Pro, and iPhone 16 and later. A client on an older Mac is a client who cannot see your cut, and you will find out by email rather than by testing.
HEVC is more available than its reputation suggests, but the conditions are real: hardware support on Windows for Chrome and Edge, a Store extension on Edge, and Firefox support that only begins at recent versions per platform. H.264 asks none of those questions. When the recipient is unknown, H.264 in MP4 is the choice that does not generate a support thread.
One caveat that applies to the master and not the review cut: no vendor documents 10-bit 4:2:2 HEVC decode in a video element, in either direction. Our side never re-encodes, so a file like that is stored and served untouched. What a given browser does with it is not documented by anyone, which is a good reason to keep the review cut conservative and let the master be the master.
How heavy the review cut should be
Nothing here is re-encoded,
so the number you pick is the number they see.
On a platform that re-encodes, an upload bitrate is a suggestion and the platform decides the rest. Here the file you upload is the file that streams, so the export setting is the final answer. Two platforms publish target tables worth borrowing as a floor.
YouTube figures are its SDR recommendations, standard frame rate then high frame rate, from its upload encoding settings page fetched 11 September 2026; it publishes a separate HDR table with higher numbers. Vimeo figures are from its compression guidelines page fetched the same day. Both are upload-target recommendations published by those platforms for their own re-encoding pipelines, not delivery bitrates, and neither is a limit here.
There is no bitrate ceiling and no resolution ceiling on this side, and no bandwidth is metered on any plan, free included. Plans have storage, seat and caption allowances; streaming has no extra charge. That removes the usual reason people starve a review cut, which is fear of a bandwidth bill, and leaves only the real question: is the picture good enough that a note about the picture means something.
8K review cuts play when the viewer hardware decodes them, which is a caveat you should carry rather than assume away. If the client is approving an 8K master, send them a 4K review cut and keep the 8K conversation for the room with the reference monitor.
Where the master lives
A finishing master gets watched once,
then it should stop paying hot rent.
A DNxHR master is large and it is consulted rarely. That is the exact profile cold storage exists for, and it changes which plan makes sense for a delivery shop.
Starter is free with 5 GB hot and one film at a time. Max includes 3 team seats and Studio includes 5. Extra team seats are $25 a month or $300 a year, the same on every paid plan, with no storage attached to a seat. Max and Studio include archive storage; archive add-ons are available on every paid plan. Verified on the pricing page, 11 September 2026.
Archive after sign-off, not before
A cold master does not stream, embed or review. Move it once the client has approved the review cut and the downstream team has taken its copy, not while anyone might still ask for it.
The re-hydration allowance is a real number
You can pull back twice your cold pool in a calendar month, and the counter resets on the 1st. Plan a conform week around that rather than discovering it on the Thursday.
How the master gets to cold
The web dashboard moves masters up to 20 GB. Anything larger moves part by part through the macOS app. Archiving frees the hot space immediately, and restores are size-verified.
The review cut stays hot
It is small, it is the thing people open, and it is the file every link and comment is attached to. Leave it where it is and let the master do the travelling.
When this is the wrong workflow
Two deliveries that need no master,
and one that should still go on a drive.
Not every job that produces a DNxHR file needs to deliver one, and saying so is cheaper than shipping one nobody opens.
The client only ever watches
If the file will never be opened in an editing application by anyone other than you, the master is dead weight in the handoff. Send the review cut on its own. It is faster to make, faster to open, smaller to store and cheaper to keep. A marketing contact who asked for a link to show their director does not want a finishing master, and giving them one produces a confused email rather than an approval.
The recipient works in a different finishing format
Check before you export, not after. If the house you are delivering to finishes in ProRes or expects an image sequence, a DNxHR master is a conversion job you have handed to someone else, and conversions get done badly by people who did not ask for them. The general version of that conversation, across formats and deliverable specs, is on how to deliver final video files to clients.
The volume is a drive job
A season of masters on a deadline is still a courier problem in a lot of cities, and pretending otherwise costs a delivery date. The hybrid is what usually wins: put the review cuts online the day picture locks so notes and approvals run at internet speed, and let the drive carry masters that have already been signed off. Nothing has to be reshipped because of a note that arrived late.
Whichever route the master takes, the principle behind this page does not move: the file you upload is the file that comes back out, with no encode step at either end. That is the same promise explained at length in video hosting that does not compress your file.
Questions
Frequently asked
Can a client watch a DNxHR file in their browser?
No. Browser playback here is H.264, HEVC and AV1. ProRes 422, ProRes 4444 and DNxHR are hosted for client download, not streamed. That is not a limitation you can configure around by choosing a different profile or a different wrapper. It is why the delivery needs a second file: a review cut in a codec the browser decodes, sitting beside the master.
How do I send a DNxHR master to a client without shipping a drive?
Upload it and host it for download. The file is stored and served as the exact bytes you uploaded, with no transcode anywhere in the path, so what lands on the client machine is what left your timeline. Send the review cut in the same handoff so the approval can start while the master is still downloading.
Which codec should the review cut be?
H.264 if you want the widest reach. MDN documents AVC support in all versions of Chrome, Edge, Firefox, Opera and Safari, with the note that Firefox depends on the operating system codecs. HEVC and AV1 both reach most of the same people but carry conditions worth reading before you rely on them, which is why they are in the table above rather than in a sentence here.
Does the client get the exact file I exported?
Yes. There is no encode step at upload and none at playback. The player streams the bytes you uploaded, and the download hands over the same stored object. Nothing is optimised, repackaged or regenerated on the way through, in either direction.
What bitrate should the review cut be?
Nothing here meters bandwidth, so the number is a picture-quality decision rather than a cost one. YouTube and Vimeo both publish upload-target tables, quoted above, and they are a reasonable floor to work from. Remember what they are: recommendations for uploads that those platforms will then re-encode. Nothing is re-encoded here, so whatever you upload is exactly what the client sees.
Is the review cut the same thing as a proxy?
No, and conflating the two costs people a day. A proxy exists so an editing application stays responsive. Apple documents Final Cut Pro proxies as Apple ProRes 422 Proxy or H.264, at frame sizes from 12.5 percent to 100 percent of the original, with the original media always retained. A review cut is a delivery: full frame size, made from the locked timeline, meant for a client and not for a timeline.
Can I archive the DNxHR master after the client signs off?
On Max and Studio, yes. Those two plans include cold storage, and archiving frees hot space immediately. The re-hydration allowance is twice the cold pool per calendar month and resets on the 1st. Two things to plan for: a cold master does not stream, embed or review, and the web dashboard moves masters up to 20 GB while larger ones move part by part through the macOS app.
Host the master, stream the review cut
Upload the DNxHR master and a browser-playable review cut to the same library, collect the notes on the cut, and hand the master over when it is signed off. Plans have storage, seat and caption allowances; streaming has no extra charge. Views, uploads and viewers are not capped on any plan.
Sources
- 1.Web video codec guide (MDN) (browser support for H.264, HEVC and AV1 decode in a video element; fetched 11 September 2026)
- 2.Media container formats (file types) (MDN) (MP4 supported by all browsers; QuickTime described as a legacy container; fetched 11 September 2026)
- 3.Codecs in common media types (MDN) (a container type alone does not describe the format of the media inside it; fetched 11 September 2026)
- 4.YouTube recommended upload encoding settings (YouTube Help) (SDR and HDR upload-target bitrates by resolution, container and audio settings; fetched 11 September 2026)
- 5.Video and audio compression guidelines (Vimeo Help Center) (recommended bitrates by resolution, frame rate and audio guidance; fetched 11 September 2026)
- 6.Create optimized and proxy files in Final Cut Pro for Mac (Apple Support) (proxy media is ProRes 422 Proxy or H.264, 12.5 to 100 percent frame size, originals always retained; fetched 11 September 2026)
- 7.uncompressed.io pricing (plan storage, seats, storage blocks, and unlimited views, uploads and viewers on every plan; verified 11 September 2026)
- 8.uncompressed.io Terms (Plans have storage, seat and caption allowances; streaming has no extra charge, no bandwidth caps, files are never sold or used to train AI; verified 11 September 2026)