How to Burn In Timecode for Final Cut Pro Client Review Without Baking It Into the Master

There's an old fear that runs through post-production circles, the client review copy accidentally becomes the delivered master, timecode burned in, a watermark stamped across the lower third, and now you're re-exporting under deadline pressure because nobody separated the review file from the final one cleanly enough. Editors working in Final Cut Pro run into this constantly, because the instinct to bake timecode straight into a share export is understandable, clients need a precise way to reference a moment, "the note is at 00:04:12:08," but baking it in permanently means you've now got a burned-in export sitting in your project folder that looks dangerously similar to your actual deliverable, and everyone who's shipped a project under deadline pressure knows exactly how that mix-up happens.

Why Timecode Burn-In Still Matters When Everyone Has Comment Tools

You'd think frame-accurate comment tools would have made burn-in obsolete, and in a lot of workflows they have, but there are still real situations where a visible timecode overlay earns its place, client calls where someone's reading timecode out loud off screen to a colleague who isn't looking at the same review link, broadcast delivery checks where an engineer needs to visually confirm timecode against a reference monitor, and legal or compliance reviews where a burned-in code becomes part of the audit trail on the file itself rather than living in a separate system. For those situations, burn-in isn't outdated, it's just a tool that needs to live in the right lane, on a review export, never anywhere near the master.

Setting Up a Clean Burn-In Export in Final Cut Pro

Final Cut Pro handles this through a share destination built specifically for open format or a compressor preset with a timecode overlay generator applied, rather than baking the code into your primary edit timeline. The key discipline here, and this is basically the whole trick, is treating the burn-in export as its own destination entirely separate from your master destination, not a toggle you flip on and off on the same export. We tell editors to build two distinct share presets from day one on any project, one clean, one burned, and to never let the burned preset inherit the same file name pattern as the clean one, because a same-named file sitting in two different folders is exactly how the wrong version ends up in a client's inbox at 11pm before a delivery deadline.

Set this up once and it's basically zero ongoing effort. Duplicate your existing Compressor or Share destination, rename it something unmistakable like "REVIEW_BURNIN" so it can't be confused with "MASTER_DELIVERY" at a glance, and add the timecode generator as a filter on that duplicate only. From that point forward, every project you start inherits both destinations automatically, and the only decision left at export time is which one you're clicking, not whether you remembered the overlay correctly under deadline pressure.

What to Actually Put in the Overlay

A good review overlay includes source timecode, a project or client watermark if the content is sensitive enough to need one, and ideally a version label so a client glancing at a frame grab from the review can tell you exactly which cut they're referencing without you having to ask. Resist the urge to overload the overlay with every piece of metadata FCP can generate, audio levels, frame rate, codec info, none of that helps a client leave a useful note and it just clutters the image enough that they start ignoring the overlay entirely, which defeats the purpose.

Why the Comment Layer Still Matters Even With Burn-In

Here's the thing a lot of editors get wrong, they think burn-in alone solves the note-taking problem, but a client reading a timecode off a burned-in overlay and typing it into an email is still doing manual translation work that introduces errors, off-by-one-frame mistakes, transposed digits, notes that reference the wrong scene because the client misread a code that flashed past during playback. You know exactly what I mean if you've ever gotten a note that said "the issue at 4:12" only to find nothing wrong at that frame because the client actually meant 4:21. Pairing the burned export with a proper review link where the client can click directly on the frame and leave a comment that auto-captures the exact timecode removes that translation step entirely. At that point the burn-in becomes a backup reference rather than the primary mechanism, useful for verbal calls and screenshots shared outside the platform, but not the thing carrying the weight of the actual note.

This is exactly the layer we built PlayPause around. You upload your burned review export, the client watches it inside a Client Review Portal, and every comment they leave is pinned to the frame with the platform's own precise timecode reference, which means even if your burn-in overlay is there for visual context, the actual note-taking never depends on someone reading digits correctly off a moving image.

Keeping the Master Genuinely Clean

The bigger risk isn't really the burn-in itself, it's process discipline around what happens after the review round closes. We've talked to editors who keep their clean master and their burned review export in the same folder with similar names, and inevitably, on a tight enough deadline, the wrong one gets attached to the final delivery email. The fix is boring but effective: keep burned review exports in a clearly separate folder, ideally one that gets archived or deleted once a project wraps, and never let your delivery folder contain anything but the clean, un-watermarked master. If you're the kind of editor who batches deliveries across multiple client projects at once, this discipline matters even more, because the chance of grabbing the wrong file from the wrong project folder goes up with every simultaneous deliverable you're juggling, something anyone managing Multi Projects at once has felt the sting of at least once.

• Two share presets, never one toggle
• Distinct file naming between burned and clean exports
• Burned exports live in a folder separate from delivery masters
• Client comments captured through the platform, not transcribed from the overlay
• Master files never touched by watermark or overlay generators

What Happens When Burn-In Gets Skipped Entirely

It's worth addressing the other failure mode too, editors who skip burn-in altogether and rely purely on a review platform's own timecode display. That works fine as long as the client is always reviewing inside the platform, but it falls apart the moment a note gets forwarded outside the system, a producer takes a screenshot and texts it to a director who isn't logged into the review link, or a client exports a frame grab to include in an internal deck. Without any visible timecode on the image itself, that screenshot becomes untraceable, nobody can look at it later and say with confidence which frame or which version it came from. A light, minimal burn-in on the review copy protects against exactly that scenario, giving every frame a reference point that survives even when it leaves the platform it was reviewed in.

When a Client Insists on Emailed Screenshots Anyway

Even with a review link and pinned comments doing most of the work, some clients are going to keep taking screenshots and pasting them into an email or a deck no matter what tooling you give them. Rather than fighting that habit, plan for it, because a burned-in timecode is exactly what makes those screenshots useful instead of useless once they leave your review system. If your overlay is legible and consistently positioned, a screenshot dropped into an internal Slack channel or a client's status deck still carries enough information for someone to trace it back to the right frame and version, saving a surprising number of "wait, which cut is this from" conversations down the line.

A Middle Ground Worth Considering

Some editors split the difference by keeping the overlay extremely minimal, timecode only, small, corner-positioned, low opacity, so it barely interferes with judging the actual image but still gives a frame enough of an anchor to be traceable if it escapes the review system. That's usually the right call for narrative or commercial work where the client cares about image quality during review. For broadcast or legal-adjacent deliveries where the burn-in itself needs to be unambiguous and easily readable, a bolder, higher-contrast overlay makes more sense, even if it's slightly more intrusive on the image. The point isn't that one style is universally correct, it's that the choice should be intentional rather than whatever FCP's default preset happens to output.

Building This Into Your Actual Delivery Checklist

None of this works as a one-time setup, it has to become part of how every project gets delivered, which is why we push editors to bake it into whatever delivery checklist they already run through before a project wraps. A checklist that already covers codec, frame rate, and audio levels should also cover which export got the burn-in treatment, where that export lives, and confirmation that the clean master never had a watermark generator anywhere near its render path. For teams working across Broadcast News or Corporate Video deliveries where multiple stakeholders sign off before final delivery, that checklist discipline is often the actual difference between a smooth wrap and a scramble the night before air date.

A Real Near-Miss Worth Learning From

We heard about a case where a post house delivering a thirty-minute corporate training video came within one click of shipping the burned review copy as the actual master, because both files were rendered the same afternoon, sat in the same exports folder, and were named almost identically apart from a "_REV" suffix easy to miss while scanning quickly at 9pm. The mistake was caught only because the assistant editor double-checked frame one before uploading to the client's delivery portal and noticed the visible timecode where none should have been. Nothing bad happened on that project, but it's the kind of near-miss that convinces a team to finally build the separate-folder, separate-naming discipline properly instead of trusting everyone to remember which file is which under deadline pressure.

Where This Fits Into a Broader FCP Review Habit

If your documentary or narrative team is also managing multiple cut versions across a long edit, the same discipline about keeping review copies distinct from masters applies to version tracking generally, and it's worth reading our piece on keeping client notes tied to the correct Final Cut Pro version if that's a recurring headache on your team. Adobe's video blog has covered similar version-hygiene issues from the Premiere side of the industry, and the underlying principle holds regardless of NLE, review copies and masters need to be structurally impossible to confuse, not just conventionally different.

Send Review Copies That Never Get Mistaken for the Master

If your current process relies on remembering which export has the burned timecode and which one is the clean master, you're one deadline-week mistake away from delivering the wrong file. Set up a review link inside PlayPause where clients get frame-accurate comments without you ever risking your master, and keep your delivery folder genuinely clean. Contact PlayPause to get your review workflow set up, or browse PlayPause pricing to see how a flat-price workspace handles review exports for your whole team.