Password Protect a Video File or the Link? A Guide for Client Deliveries
Encrypted zips on Mac and Windows, what they cost your client in downloads and unzipping, and why I protect the review link instead of the file until final delivery.
A 15 GB video file is roughly what a nine minute brand film weighs as ProRes 422 HQ at 1080p, because that codec runs at about 220 megabits a second, and 540 seconds of that lands close to 15 GB. That's usually the file behind a message my agency gets a few times a quarter, a client asking us to send the cut password protected because their legal team said so.
So let's do the math on what it takes to password protect a video file that size the way most guides suggest, right. You wrap it in an encrypted zip, the client downloads 15 GB, and their laptop needs another 15 GB free to extract it, so that's 30 GB of disk for one cut. If the film goes three rounds, you've pushed 45 GB through a client's office connection, all so a marketing manager can type "logo feels small around 2:14" into an email thread.
I run a video editing agency and co-founded PlayPause, a review platform, so you can guess where I'll land, but to be very honest the file methods are real and I still use them at one stage of every project. What the usual guides skip is that the right answer depends on whether your client needs to watch the video or actually own it.
The three ways people password protect a video file
Basically, when somebody sets out to password protect a video file, they end up doing one of three things, right. The first is an encrypted archive, a zip or a 7z with a password, which almost every guide leads with because it's free and works on any file. The second is an encryption container, like an encrypted disk image on a Mac or a VeraCrypt volume, where the video sits inside a box that only opens with the password. The third leaves the file alone, so you upload the video, put the password on the link, and the client watches in a browser without the file landing on their machine.
The thing that trips people up, especially editors searching how to password protect an MP4, is expecting the format itself to have a lock hidden somewhere in the export settings.
The MP4 container has no built in way to ask for a password, so every tool that promises to lock an MP4 is really wrapping it in an archive, a container or its own player.
Some of the sketchier lock tools turn your video into their own player file, often a Windows program a Mac client can't even launch, so for client work I stick to the boring, well known options. Cloud storage links follow the same logic, as I covered in password protecting a Dropbox link.
How to zip a video with a password on Mac and Windows
If you've decided the file itself needs the lock, an encrypted zip is the practical way to do it, and the catch here is that two choices in the dialog decide whether the protection is real or mostly cosmetic.
On Windows with 7-Zip
The built in Send to compressed folder option in Windows can't add a password, so on Windows I use 7-Zip, which is free. Pick AES-256 as the encryption method rather than ZipCrypto, the older scheme zip archives default to, and set the compression level to Store, because video is already compressed and squeezing a 15 GB ProRes file just burns time.
Choosing 7z also hides the file name, which matters more than people expect, because an archive called Launch_Film_UNANNOUNCED.zip tells anyone who spots it exactly what's inside, even if they can never open it.
On a Mac with Terminal or Disk Utility
The Finder's Compress option has no password setting either, so a Mac gives you two built in routes. The quick one is Terminal, where zip -e client-cut.zip client-cut.mov asks for a password and builds the archive, but it uses the old ZipCrypto scheme, which is fine against a curious colleague and weak against anyone who really tries. The stronger one is Disk Utility, where File, then New Image, then Image from Folder lets you choose 256-bit AES and gives you a password protected .dmg. I'm pretty sure you can already see the problem, right, a .dmg opens beautifully on a Mac and not at all on a Windows laptop without extra software.
Picking a password that survives a forwarded email
Here's a worked example from my own projects, because the strongest encryption in the world doesn't matter when the password is Brand2026 and half the client's team could guess it. I use a passphrase of four or five unrelated words, something like copper lantern seven harbour drift, which is long enough to stop being the weak link and still easy to read out over a call. Every project gets its own, because one password reused across clients means a single leak opens every cut you've ever sent.
What your client has to do to open it
The half nobody writes about is the client's side, right, because they download the whole thing first, with no preview to tell them it's even the right cut, and then their built in unzip tool has to cope with the encryption you picked. In my experience the Mac's Archive Utility won't open an AES-256 zip, and plenty of corporate Windows laptops can't install 7-Zip without an IT ticket. So the next message you get is usually a screenshot of an error instead of feedback on the cut, the same mess I untangled for a client who can't open the video file.
Why file level encryption is painful for client review
Once the encrypted file goes into a real review cycle, the costs stack up round after round, so here's that illustrative math again for the nine minute film at around 15 GB a cut.
And storage is honestly the smaller problem, right. Every new cut means a new archive, another download and another unzip, and the client's Downloads folder now holds decrypted copies of an unreleased film with no protection at all. The way I explain it to my editors is that encryption protects a file while it's stored or moving, and the moment it's decrypted so someone can use it, it's just a file again.
Then there's the feedback, because the client watches the extracted file in QuickTime or VLC and writes notes from memory, "around the two minute mark", "the bit after the CEO talks", and so on. You spend the next round matching vague descriptions to frames. And the password travels with the file forever, right, so whatever you typed into 7-Zip in March still opens that archive in November on whichever laptop it got forwarded to.
To be very honest, I think this is why so many editors quietly stop encrypting after one project, because once the password becomes the thing the client resents, people find a way around it, usually by asking you to just send the file normally next time.
Password protecting the link instead of the file
So here's what I actually do to password protect a video for a client while they only need to watch and comment. I upload the cut to PlayPause, which makes a streaming copy for browser playback, so the ProRes original is never touched and nobody downloads 15 GB to press play, as our page on proxy and transcoding explains. Streaming is basically how most web video works, where the browser fetches small pieces as it plays, the idea behind formats like HTTP Live Streaming, so a nine minute film starts without a giant download first.
Then I share it with a password on the link, which is available on every PlayPause plan, and I send the password through a different channel, usually WhatsApp or a quick call, so a forwarded email only carries half the key. The client opens the link in any browser with no account and no install, types the password, and leaves comments that stick to the exact frame, and they can draw on the frame when "the logo" could mean one of three logos.
What a zip can never give me is control after sending, right. If the link ends up somewhere it shouldn't, I revoke it instantly, and on Creator and up the who-watched analytics show who opened it, when, and from which city. So if a cut meant for three people in Mumbai shows an open from a city I don't recognise, I see it the next time I check and kill the link, whereas with a zip I'd never have known. The next cut goes onto the same card as MV2 in the version stack, instead of zips called final, final2 and final_REAL.
a full download before anyone can watch, a password that works forever and no idea who opened the file
browser playback from a streaming copy, frame-accurate comments, instant revoking and a record of who watched
The click by click setup is in how to password protect a review link, and if you're weighing other hosts, my take on Vimeo private links versus passwords covers that trade off. Freelancers usually start with secure share links for freelance editors, the rest of the controls live on our sharing and security page, and uploading a video for a shareable link starts from scratch.
What a password cannot do once the file is downloaded
A password controls who can open something, and once a file is open and saved, the password's job is finished for good, right, because the decrypted copy can be duplicated, uploaded or dropped into a shared drive, and nothing you do afterwards reaches it.
A password protects the door, not the copy, and once a client holds the decrypted file, the only security left is how far you trust the person holding it.
Links share that limit, and the difference is only in what you've handed over. With a protected link the client has watched a streaming copy, and if I revoke, the door closes, whereas with a zip they hold the file itself and there's no door left for me to close, does that make sense, right. And let me be very honest about the other limit, which is that nothing stops someone pointing a phone at their screen. For really really sensitive material I keep the viewer list short and get the NDA signed before anyone sees a frame, which I dig into in whether video password protection is enough, and legal teams can see how I handle confidential deposition review links.
Choosing the right protection for each stage of a project
At the end of the day the real question is whether the person on the other side needs to watch the video or own it, and a normal project moves through both stages, so here's how I split it in my agency.
Rough cuts and review rounds
While the client is only watching a rough cut and commenting, the link wins every time, with the password sent separately and the link lifetime matched to the job. On Creator, share links and the files behind them expire after 30 days, on Agency links last 90 days, and on Enterprise they never expire, so I pick the plan that fits my turnaround rather than babysit expiry dates. The wider review side is covered in sharing a video for review securely.
Final delivery
Once the film is approved and the client needs the master, a file genuinely changes hands, and for most clients a clean handover is fine, as I laid out in delivering final video files to clients. This is the one stage where an encrypted archive earns its place, for instance when an unreleased launch film goes to a PR agency that just needs the master sitting safely on a drive until launch day.
Raw footage and sensitive handoffs
Raw footage is where I get strict, especially raw interview dailies where people speak candidly before anything is cut. For those handoffs I use a 7z with AES-256 or an encrypted disk image, share the password by phone, and keep a note of who received what, and trust me on any level, that note is the thing you'll wish you had six months later.
- Does the client need to watch the video or own the file
- Is the password travelling through a different channel than the link
- Does the link lifetime match the project turnaround
- Can I revoke access the moment the project wraps
Frequently asked questions
Can you password protect an MP4 file directly?
Not inside the file itself, because the MP4 format has no password field, so no player will ever ask for one. You can wrap it in an AES-256 zip or 7z, or put it in an encrypted disk image, or leave the file alone and protect the link, which is what I do whenever the client only needs to watch.
Is a password protected zip secure enough for client footage?
With AES-256 and a long passphrase the encryption itself is strong, and the weak points are everything around it. The password often travels in the same email as the file, it never changes, and once extracted the video has no protection at all. For review rounds I'd rather protect a link I can revoke, and I save encrypted archives for masters and raw footage.
How should I send the password to my client?
Never in the same message as the file or the link, because a forwarded email then carries both halves of the key. I send the link by email and the password over WhatsApp or a short call, and every project gets its own passphrase, so if one ever leaks it opens that single cut and nothing else you've sent over the years.
Which PlayPause plan includes password protected links?
Every plan has them, right, including Creator at $9 a month, along with instant link revoking and commenting from a link without an account. Where the plans differ for sharing is mostly link lifetime, which I covered above, plus guest version upload from Agency up and a custom share domain with white-label on Enterprise, along with more members and storage at each step.
If you're tired of zipping cuts and walking clients through unzip errors, try the link route on your next review round. Every plan starts with a 7-day free trial, and you can compare Creator, Agency and Enterprise side by side on the PlayPause pricing page before you pick one.
So yeah. That's my way of saying it.
Saumyajit co-founded PlayPause after years watching review and approval quietly eat creative teams' deadlines. He writes about the workflow side of video, feedback, versioning, and getting to a clean sign-off.
Related resources
Keep reading
Bring your team into one review space
Centralize feedback, lock approvals, and deliver faster, start free today.
Sign Up for Free