Client delivery

How to password protect a video link for a client.
Four steps, on any plan, including the free one.

A password on a film is the shortest distance between a rough cut and a client who can watch it without an account. Here is how to set one, what the server actually checks, how the same job costs money on Vimeo and does not exist on YouTube, and the part most guides leave out: what a password does not protect you from.

See how access control works

No credit card required. Cancel any time.

Updated September 2026

The procedure

Four steps,
and one habit that makes it worth doing.

Setting the password takes under a minute. The habit in step four is the part that decides whether the password was security or theatre.

Upload the film, or open one you already have

Drop the file in the dashboard. Files go up to 50 GB each. The uploader survives moving around the app, so you can keep working while it runs; it does not survive a reload, in which case you re-drop the same file and it continues from the last finished part.

Set the visibility to Password

Every film has five visibility modes: Private, Password, Unlisted, Public and Embed only. Choose Password. There is no plan check on this, on the free Starter plan or any other.

Type the code, and save

Any string works. If you type something containing an @ character, the gate switches into email allowlist mode instead and asks the viewer for their address. Save, and the film is gated from that moment.

Send the link and the code in two different places

Put the link in the email and the code in a text message, or in the call you are already having. A code pasted directly under the link it unlocks is not a second factor, it is a longer link.

After that the film behaves like any other. You can rename the slug, so the address reads uncompressed.io/yourhandle/the-cut rather than an id. You can upload a new version of the file onto the same row, which keeps the id, the slug, the visibility, the password, every embed and the view count, so the client refreshes and sees version two at the same address. And you can change or clear the code whenever you want without touching the URL.

One behaviour to remember

Switching the film to another visibility mode clears the access code. If you flip a film to Private for a week and then back to Password, set a new code. Nothing is silently left open: Private means only you, and the old code is gone rather than dormant.

What happens when the client types it

A comparison on the server,
not a script in the page.

The weakness of most password gates on the web is that they are decorations. The page ships with the answer in it, and the check runs in the browser that is trying to get in.

Ours runs the other way around. When a viewer submits the code, the server derives an HMAC-SHA256 of the film id and the code and sets that value as a cookie, which is httpOnly, secure, sameSite lax and lasts 30 days. On every subsequent request the watch page compares the cookie against the same computation before it renders anything. If the comparison fails, the film does not render. The code itself never travels back to the browser, so there is nothing to read in the page source, nothing in the DOM and nothing in a network response to inspect. Guessing is limited to 20 attempts per IP address per hour.

attempts an hour

per IP address, then the gate stops answering

30 days

the cookie lasts

httpOnly, secure, sameSite lax, so a client types the code once

codes in the page source

the server compares a hash; the code never comes back to the browser

what this costs

the free plan has passwords, 5 GB, one film at a time

Two consequences worth stating plainly. A password film never renders inside an embed, because a gate that an iframe can walk past is not a gate; if you need the film inside a page, that is what Embed only is for. And whatever plays behind the gate is the exact file you uploaded, with no transcode anywhere in the path, which is the reason a client watching a graded cut through a password page is looking at your grade rather than a platform’s rendition of it.

The same job, five places

Everyone has an answer,
the plan you have to be on to use it.

Password protection is not an exotic feature. What differs is the price of the plan that exposes it, what the client sees once they are in, and what happens to the gate when your subscription lapses.

Vimeo

YouTube

WeTransfer

Dropbox

Passwordon the link

Every plan,free Starter included

“Available withpaid plans”

No password settingexists

Free plan, setbefore or after sending

Listed for Professionaland business plans; Basicand Plus are not on the list

Cheapest planthat unlocks it

Starter, $12 a monthbilled annually,$20 month to month, USD

Not availableat any price

$0, and it“costs nothing extra”

Not on Basic or Plus;no price publishedfor the lowest tier listed

What the clientwatches

The exact fileyou uploaded,no transcode

A file “re-encoded intoseveral formats”

YouTube “alwaysre-encodes videos”

Browser preview for MP4and MOV up to 300 MB;otherwise they download blind

Preview up to 1080p onBasic, up to 2160p on paid

If the planlapses

Nothing to lose:the free planhas passwords

“Password, Unlisted andEmbed-only videos will beswitched to Private”

No passwordto lose

Free links expire after“a maximum of 3 days”

Password and expiryare not listed forBasic or Plus

Cap onpeople watching

No bandwidth meter;storage is the only meter

2 TB a month onself-serve accounts

Not published

Free: 10 transfersor 3 GB per 30 days

Standard 1 TB a day;no free-tierfigure published

Every cell is quoted or summarised from the vendor's own help centre or pricing page, fetched 5 September 2026 and listed in the sources below. Vimeo figures are in USD; the pricing page localises, and this machine renders Canadian dollars, so the USD figures are the ones taken from the page's own plan data.

The row that decides most arguments is the last one nobody checks. On Vimeo, the password is a paid feature, and the help centre is explicit about what happens if the subscription stops: password, unlisted and embed-only videos are switched to Private. That means a link you sent a client eight months ago stops working the week your card fails, and the video is restricted rather than deleted, so it comes back when the account fits again. On YouTube there is no password at all. Unlisted is not a substitute, because unlisted videos, in Google’s own words, can be seen and shared by anyone with the link, and Private requires the viewer to be signed in to the account the video was shared with, which turns a client into a Google-account problem.

Honest framing

Three cases where
you should not move for this.

You are sending files, not screenings

If the client never watches in a browser and only wants the deliverable on their drive, WeTransfer already does this. A password costs nothing extra on the free plan, and the 3-day link life is a feature when you want the file gone. The catch is only a catch if someone needs to watch: browser preview covers MP4 and MOV up to 300 MB, and a finished film is not 300 MB, so your client downloads blind.

The video is marketing, and reach is the point

A password is the wrong tool for anything meant to be found. If the goal is a public page, search traffic and a share button, YouTube's total absence of a password is irrelevant to you and its distribution is not something we replace.

Your team already lives in Dropbox

If the files, the contracts and the client folders are already there and everyone is on a plan that includes link passwords and expiry, adding one more tool to gate one more video is friction for its own sake. Check which plan you are on first: link passwords are listed for Professional, Essentials, Standard, Advanced, Business, Business Plus and Enterprise, and Basic and Plus are not on that list.

The part most guides skip

A password stops a casual forward,
not a determined recipient.

This is worth being blunt about, because the whole value of the feature depends on understanding what it is for.

A shared code is a shared secret. Anyone you give it to can pass it along with the link, and the gate has no way to tell the difference between the producer you sent it to and the friend she forwarded it to. A viewer who gets in can point a phone at the screen. A viewer with the download toggle on has the master. None of that is a flaw in the implementation; it is what a password is. What a password actually buys you is real, and it is this: the link is useless on its own, so a URL that leaks in a forwarded thread, a shared inbox, a Slack channel or a screenshot does not become a viewable film. That covers the overwhelming majority of real incidents, which are accidents rather than attacks.

If the exposure is bigger than an accident, the honest answer is that you need a different mechanism, not a longer password. Three steps up the ladder, in order of how much they cost you in convenience:

Use the email allowlist instead of a code

Put an @ in the access code and the gate asks for an email address rather than a shared secret. The link plus a stranger's inbox is not enough. It is the cheapest real improvement available, and it costs the client one extra field.

Rotate the code, and use the fact that it is free to rotate

Because the code is a field on the film and not part of the URL, changing it costs nothing and breaks nothing. New code after a review round, new code when someone leaves the project. The link you already sent keeps working for everyone who gets the new code and stops working for everyone who does not.

Move the master into Vault when the file itself is the risk

Vault masters do not play on the web at all. They open only in the macOS app, with screen capture blocked, a visible per-session watermark on the frame, an invisible per-person forensic mark, AES-256 encryption at rest and short-lived links. That is a different threat model from a password: it assumes the person you invited is the leak.

Know what is not shipped

We do not claim DRM. Studio-grade DRM on our player is roadmap and we will say so until it ships. The Vault's tamper-evident view log is written by the app, but no web dashboard surfaces it to you today, so do not buy the tier expecting to read that log in your browser this month.

One link, two jobs

The page that gates the review
can also hand over the master.

Most client work ends with the same two messages: here is the cut, and here is the file. Each film has an original-file download toggle, with no tier gate, so the password page can do both. The client types the code once, the cookie holds for 30 days, they watch the cut in the browser at full bitrate, and the same page offers the master. No second service, no second link, no transfer that expires in three days while your client is on a shoot. The only exception is a vaulted film, where the download toggle is forced off, because handing over a local copy is precisely what that tier exists to prevent.

If your next question is which mode to use for a screener that is going to a festival programmer or a distributor rather than to a paying client, that is a different set of trade-offs and it has its own page: send a private video screener. If you need to take access back from someone who already has the link, start with revoke access to a shared video link. And if the job is really the handoff of finished files, see delivering final video files to clients.

Questions

Frequently asked

Do I need a paid plan to password protect a video?

Not on uncompressed.io. Per-film passwords are available on every plan, including the free Starter plan, and there is no tier check anywhere in the code. The free plan's only limits are 5 GB of storage, one film at a time, 20 caption minutes a month and no Vault. Password, unlisted, embed-only, custom links, original-file downloads and the unbranded player are all free. On Vimeo, the same feature is different: the help centre lists Password, Unlisted and Embed only as available with paid plans, while Public and Private are available with all plans.

Does my client need to create an account to watch?

No. Clients never make an account. At most they type the code you gave them into the gate on the watch page. That is the whole interaction. It matters more than it sounds: a signup wall is the most common reason a client watches on their phone at midnight instead of at their desk, and the most common reason a producer forwards the file to a personal address instead.

Can I change the password later without breaking the link?

Yes. The access code is a field on the film, so you can change it or clear it at any time and the URL, the embed and the view count stay exactly as they were. One thing to know: switching the film to another visibility mode clears the code, so if you set it back to Password later you will need to type a new one.

Can I let a specific list of people in instead of sharing one code?

Yes. If the access code you set contains an @ character, the gate switches to an email allowlist: the viewer types their email address and is let in only if it matches. It is the right mode when the film is going to a named group rather than to whoever is holding the link, because it removes the shared secret that everyone in the thread can forward.

Will the password stop someone from downloading or re-sharing the film?

No, and any guide that tells you otherwise is selling something. Anyone who has the code can pass it on with the link, and a viewer who can play a film can record their screen. A password raises the cost of a casual forward. It does not defeat a recipient who has decided to leak. What changes that calculation is Vault: masters play only in the macOS app, screen capture is blocked, every session carries a visible watermark and an invisible per-person forensic mark, files are AES-256 encrypted at rest and links are short-lived.

Can I use a password on an embedded player?

No, by design. A password-protected film never renders inside an embed; the gate would be pointless if a page could iframe past it. If you need the film inside a page, use Embed only, which plays in iframes and returns 404 on the public watch routes to everyone but you. Password and Embed only are two of five visibility modes: Private, Password, Unlisted, Public and Embed only.

Can the same password-protected page deliver the final file?

Yes. Each film has an original-file download toggle with no tier gate, so the watch page can double as the delivery page: the client types the code, watches the cut, and saves the master from the same URL. The only case where the toggle is forced off is a vaulted film, where saving a local copy is the thing the tier exists to prevent.

A code your client types once, and nothing else to install

Per-film passwords are on every plan, free included. The check runs on the server, the code never reaches the browser, and you can change or remove it without changing the link.