Client delivery
A client should click a link and watch the film. Not sign in, not verify an email, not install anything. Here is which tools force an account on your viewer, which only force one on you, and how a link with a code you chose does the job on a free plan.
No credit card required. Cancel any time.
Updated September 2026
The short answer
On uncompressed.io a viewer never makes an account. At most they type a code you gave them. That holds on the free Starter plan, on Vault, and on everything between, because there is no tier check anywhere in the access code path.
The reason this question gets asked at all is that the two platforms most people try first answer it badly. A private YouTube link makes the viewer sign in to a Google account, and not just any account: YouTube’s help page states that the viewer must be signed in to the account the video was shared with. Switch to unlisted and the sign-in disappears, but so does the gate, because YouTube states that unlisted videos and playlists can be seen and shared by anyone with the link. On Vimeo the viewer is fine, and you are the one who pays: its privacy article lists Unlisted, Password and Embed only as available with paid plans.
There is a third failure mode that looks like a win. Sending the file through a transfer service asks nothing of the client, but it does not let them watch either. WeTransfer supports in-browser preview for MP4 and MOV files up to 300 MB, and says the preview plays at a slightly lower resolution than the file you get when you download. A finished film is almost never under 300 MB, so the client downloads a large file blind, then plays it in whatever software is on the machine, then writes notes with no timecode you can act on.
What you actually set
Every film in the library sits in exactly one of five states. You change it from the film’s page in one click, and the URL does not change when you do.
Only you. Nothing resolves for anyone else. This is where a cut lives between the export and the send.
The link works for anyone holding the code you set. The gate is checked on the server before the page renders. Available on every plan, including the free one.
Anyone with the link watches, nothing is listed anywhere. The right mode for a client who forwards the link internally and should not have to relay a code with it.
Open to anyone, with no gate at all. For reels and portfolio pieces, not for client cuts.
The film plays inside iframes, and both watch routes return 404 to everyone except you. Useful when the film belongs inside a page you control, not on a link that can be pasted anywhere.
Set, change or remove the password without changing the URL. The access code is a plain field on the film, so a link you already sent keeps working under the new rule.
The comparison
Two different costs get confused in this decision. One is whether your viewer has to join something. The other is whether you have to pay before you are allowed to hide a link. Every figure below comes from the vendor’s own page, fetched 5 September 2026.

Vendor pages fetched 5 September 2026 and listed in the sources below. Dropbox and Google prices render in Canadian dollars from this location, so they are omitted rather than converted. Frame.io free-plan storage is 2 GB with 2 members and 2 projects. Vimeo figures are the USD values carried in its pricing page data. Where a vendor does not publish an answer, the cell says so rather than guessing.
Read the first two rows together and the picture is clear. Frame.io is genuinely good on the viewer question: a reviewer is free and has no login. The catch is disclosed in Frame.io’s own share article, where a first-time commenter on a public share is asked to enter a name and email address, and Secure sharing is exclusive to Enterprise customers. So the client does not sign up, but they do identify themselves before their first note, and the locked-down version of sharing is not on the self-serve plans.
Vimeo passes the viewer test and fails the price test for anyone who only needs to send one private cut a month. YouTube passes the price test and fails the viewer test in the private mode, then fails the privacy test in the unlisted mode by its own definition. The transfer and drive tools do not really compete for this job at all: they move a file to a machine, and the moment your client is downloading a 40 GB master to watch a rough cut, the round trip on notes has grown by a day.
How the gate works
5
Visibility modes
Private, Password, Unlisted, Public, Embed only. All five on every plan.
20
Attempts per hour
Per IP address, on the password endpoint. Guessing a short code is not practical.
30
Days the cookie lasts
httpOnly, secure. The client types the code once, not on every visit.
0
Accounts created
Nothing to join, verify or install to watch a gated film.
The mechanism matters more than the marketing word around it. When a viewer submits the code, the server compares it against a keyed hash of the video id and the code, then sets a signed cookie. The watch page checks that cookie before it renders anything, so the film, its title and its download link are simply not in the page for someone who has not passed. The code never travels back to the browser, which means it cannot be read out of the page source by a viewer who was given the link but not the code.
One more consequence of the same design: a password film never renders inside an embed. If you want a gated cut visible on a page you control, that is what Embed only is for, and the two watch routes return 404 to everyone but you while it is set.
The one thing to get right
Closer to per-person
A shared code has an obvious weakness: everyone who has it is the same person as far as the gate is concerned. There is a second mode for that. If the access code you set contains an @ sign, the gate switches to an email allowlist. The viewer is asked for their email address instead of a code, and only the listed addresses pass. Nobody registers, nobody picks a password, nobody receives a confirmation link.
Describe it to yourself accurately, because that is what keeps it useful. It is the closest thing here to a per-person gate, and it is nothing more than that. A viewer types an address and the server checks it against your list. It is a way to stop a link from spreading to people you did not name. It is not proof of identity, and it is not an audit trail you could take to a legal argument.
The workflow
Up to 50 GB per file. Nothing is re-encoded on the way in or the way out, so what the client streams is the file you made, and there is no lower rendition for the player to quietly fall back to.
Password for a cut that must not travel. Unlisted for a client who will forward it internally and should not have to relay a code with it. Change your mind later without changing the URL.
Your handle and a film slug you choose, so the link reads uncompressed.io/yourhandle/the-film rather than a random string. Both are editable, and the slug can be renamed after you have sent it.
A per-film toggle issues a signed download of the original master to viewers who have passed the gate. There is no tier gate on it, so a free account can hand over a master when that is the deliverable.
What the client sees at the end of that is a player with no platform logo on it, on any plan including the free one. The only logo the player can show is your own, off by default. That is not cosmetic when the film is going in front of your client’s client: Vimeo states that on a Free or Basic plan you cannot remove watermarks from your videos, and YouTube’s player parameter for reduced branding is documented as deprecated with no effect.
Honestly
A link with a code is the right default for client review. It is not the right answer to every question, and two of the exceptions are common enough to name.
The analytics here are owner-only and identify visitors by a salted hash, not by name: opens, views, average percent watched, a retention curve, countries, and a per-viewer list capped at eight rows. That answers how the film was watched. It does not answer which named person watched it. If a distributor or a legal process needs that answer, use a platform with real viewer accounts, or send the file under an agreement that carries its own record.
Some agencies and studios mandate a review platform their IT department administers, with seats, SSO and centrally revocable access. That is a real requirement and a shared code does not satisfy it. Frame.io's Secure sharing, exclusive to Enterprise customers, exists for exactly this buyer. If your client's policy names a tool, use the tool.
Vault masters are a different promise: native-app only, screen-capture blocked, session-watermarked, with a forensic per-person mark. That deliberately breaks the browser link this page is about. The viewer installs an application. If a leak would cost more than the friction, that is the trade to make, and the download toggle is forced off while a film is vaulted.
Outside those three, the account requirement is a cost with no matching benefit to the person you are asking to pay it. Your client is trying to approve a cut between two meetings. Every step between the click and the picture is a step where the approval slips to tomorrow. See the plans for what each tier includes; the gates in this guide are on all of them, the free one included.
Questions
No. On uncompressed.io a client opens the link in a browser and the film plays. If you set a password on that film, the client types the code you gave them once and the browser remembers it. There is no signup step, no email verification and nothing to install, and that is true on the free Starter plan as well as every paid one.
It is checked on the server. The watch page compares a signed cookie against a keyed hash of the video id and the code before it renders anything, the cookie is httpOnly and lasts 30 days, and the code itself never travels back to the browser. Attempts are rate limited to 20 per IP address per hour, so guessing a short code is not practical.
Partly. If the access code you set contains an @ sign, the gate switches to an email allowlist: the viewer types their email address instead of a shared code, and only listed addresses pass. That is the closest thing here to a per-person gate. It is a gate, not an identity check, so treat it as a way to keep a link from spreading rather than as proof of who watched.
No. YouTube's own help page says viewers need to be signed in to YouTube to view a private video, and that the viewer must be signed in to the account the video was shared with. Unlisted avoids the account requirement, but YouTube also states that unlisted videos and playlists can be seen and shared by anyone with the link, so an unlisted link is public to whoever receives a forward.
Correct on the viewer side, and that is a real advantage over private YouTube links. The cost sits on your side: Vimeo's privacy article lists Unlisted, Password and Embed only as available with paid plans, and the cheapest self-serve tier on its pricing page today is $12 USD a month billed annually. Here those three modes are on the free plan.
You can, but your client downloads rather than watches. WeTransfer supports in-browser preview for MP4 and MOV files up to 300 MB, and says the preview plays at a slightly lower resolution than the downloaded original. A finished film is rarely under 300 MB. WeTransfer also states that Free and Starter uploads can be kept online for up to 3 days, so the link dies while the feedback is still in progress.
When you need to know precisely who watched, name by name, and an email allowlist is not enough evidence. And when the client's own security policy requires a managed review tool that their IT department controls. Both are legitimate reasons to use a platform with real accounts, and neither is solved by a shared code.
Five visibility modes, per-video passwords on every plan including the free one, a clean uncompressed.io/handle/film link, and no platform logo on the player. Nothing for your client to join.