How to send a master to a client for approval

You finished the master. Now comes the part nobody mastered: getting it in front of the client, collecting feedback, and walking away with a clear "yes." Most engineers still do this with a file-transfer link and an email, and it quietly costs them on audio quality, on clean revision notes, and on having any paper trail later. This is how to do it properly.

Why the WeTransfer + email workflow fails

It moves bytes, but a deliverable is more than bytes. The usual flow breaks down in five predictable ways:

• Lossy review. You email an MP3 "so it's small," so the client approves something that isn't the master you'll deliver.
• Vague feedback. "Turn the vocal up around the second chorus," with no timecode and no version, which means a round-trip just to find the spot.
• No sign-off. Nothing records that they approved this version. "I never said that was final" has no answer.
• Expiring links. The download dies in a week; the client comes back in a month and it's gone.
• Unprotected masters. A raw link means anyone with the URL has your client's unreleased master.

What a clean review-to-delivery flow looks like

Four steps, one link, no accounts for the client:

1. Share a lossless review link

Send a single link. The client plays the master losslessly in the browser, with no login, no download, and no MP3. They judge the actual audio you made, which is the only thing an approval should ever be based on. (If you're curious how lossy encoding changes a master, see true peak and loudness metering.)

2. Collect feedback on the waveform

Good feedback is precise. When the client pins a comment to an exact point on the waveform, "the de-ess at 2:14" replaces "somewhere in the bridge." Revision notes become a list of timecodes instead of a paragraph you have to decode.

3. Get the sign-off on the record

The single most undervalued step. When the client approves a specific version, capture it: which master, who approved it, and when. That record is what turns a future dispute into a non-event, and it marks the moment responsibility for the master transfers from you to them. (This is worth its own playbook: how to get client sign-off on a master.)

A sign-off isn't bureaucracy. It's the line between "the version we agreed on" and an open-ended revision loop.

4. Deliver the master, protected

Once it's approved, deliver the final files tied to the approved version, rather than a raw link anyone can forward. "Protected" should mean four concrete things:

• Password-protected. The unreleased master isn't reachable by URL alone.
• Revocable. You can kill the link the moment a deal changes or a file goes out by mistake.
• Download-tracked. You can see whether the client actually grabbed the files, so "I never got them" is checkable.
• Persistent. It doesn't silently expire in a week and strand the client a month later.

Two parts of this have their own playbooks: what to deliver and in what format, and how to send it privately.

Handling revisions without losing the thread

Revisions are where the email workflow really frays. Upload each new version against the same track so the client can A/B v1, v2 and v3 at the same timecode and hear exactly what changed. Ideally that comparison is loudness-matched, so the difference they react to is the work itself rather than a level bump. Open feedback carries forward to the new version, so nothing gets lost between rounds. They approve the version that's actually final.

The short version

Stop sending masters as email attachments. Send a lossless review link, take feedback on the waveform, record the approval of a specific version, and deliver protected. Your client hears the real thing, your revisions stay precise, and you keep a sign-off you can point to.

Frequently asked questions

What's the best way to send a master to a client?

Send a review link that plays the master losslessly in the browser with no login, lets the client leave timestamped feedback, and records their approval of a specific version. Once it's approved, deliver the final files password-protected. This beats emailing a lossy MP3 or a raw WeTransfer/Dropbox link because the client judges the real audio and you keep a clear sign-off.

Should I send clients an MP3 or a lossless file for review?

For approval, let them hear lossless. An MP3 sounds different from the master you'll deliver, so approving an MP3 means they signed off on something they didn't actually hear. Browser-based lossless (FLAC) playback lets them judge the real thing without downloading.

How do I prove a client approved a master?

Use a workflow that records the approval: which version, who approved it (name and email), and the timestamp. A signed-off record turns 'I never approved that' into a non-issue and marks the moment responsibility transfers.

Is WeTransfer good for delivering masters?

It moves files, but it has no review, no approval record, and links expire, so clients lose access and there's no sign-off. For deliverables, use password-protected delivery tied to the approved version instead of a raw expiring link.

How should I handle revisions?

Upload the new version against the same track so feedback carries across revisions and the client compares v1, v2, v3 at the same timecode. Then they approve the specific version that's final.