Some things you share aren’t for everyone. A design proof for one client. A beta build for fifty testers. A webinar replay promised to attendees only. The content already lives at a URL — the only problem is that a URL, once shared, is public to anyone who sees it. The usual fix is heavy: put the content behind a login, create accounts, send invites, reset forgotten passwords. For a one-off share, that’s a lot of machinery.
A password-protected link is the lightweight alternative: a short link that asks for one shared secret before it redirects. No accounts, no email capture, no visitor friction beyond a single field. This guide covers how password links work, where they beat a login wall (and where they don’t), and how to create one in under a minute.
How a password-protected link works
A normal short link answers a click with an immediate redirect to its destination. A password-protected link answers with a small password page instead. The visitor types the password; if it’s correct, they’re sent straight on to the real destination.
The important part is what doesn’t happen: the destination URL is never exposed until the correct password is entered. It isn’t sitting in the page source waiting to be read, and it isn’t leaked in a redirect header. On 302.sh, verification happens server-side, and only a hash of the password is stored — the password itself is never saved anywhere.
The password gates the destination, not just the page. Someone who opens the short link and views source finds nothing to skip ahead to.
Everything else about the link keeps working normally: clicks still show up in your 90-day analytics, the QR code still scans, and you can edit the destination later without re-sharing anything.
Why not just use a login wall?
Because for one-off shares, a login wall is where engagement goes to die. Every account a visitor has to create is a reason to close the tab; every “forgot password” email is a support thread. When the audience is “the twelve people I emailed this morning,” provisioning accounts is pure overhead — you don’t need to know who is visiting, only that they were invited.
The other common workaround — an unlisted, hard-to-guess URL — has the opposite problem: there’s no gate at all. The moment it’s forwarded, posted to a Slack channel, or picked up by a crawler, it’s effectively public, and you can’t take it back without moving the content.
Password link vs login wall vs unlisted URL
| Password link | Login wall | Unlisted URL | |
|---|---|---|---|
| Visitor effort | Type one password | Create account, verify email | None |
| Setup effort | One form field | Auth system, invites, resets | None |
| Actual gate | Shared secret, revocable | Per-user identity | Obscurity only |
| Revoke access | Change the password | Disable the account | Move the content |
| Best for | Previews, replays, embargoes | Ongoing per-user access | Truly harmless content |
What people actually protect
- Client previews and proofs. Designers and agencies share work-in-progress behind a password so a forwarded link doesn’t put unfinished work in front of the wrong audience. When the project wraps, rotate the password and the old link goes dark for everyone outside the loop.
- Private beta builds. A download or TestFlight alternative page shared with testers — gated so it doesn’t end up on an aggregator three hours after you send it.
- Webinar and event replays. “Replay for attendees only” becomes real: the password goes out in the post-event email, not on the public event page.
- Paid-community resources. Templates, recordings and files for members — with a password you rotate each month so lapsed members don’t keep access forever.
- Press material under embargo. Journalists get the link and the password in separate messages; the assets stay gated until launch day, then you simply remove the password.
- Portfolio pieces you can’t show publicly. Case studies covered by an NDA-ish handshake — shareable in a job application without being indexable by the whole internet.
What a password link is not
Be honest with yourself about the threat model. A password-protected link is lightweight access control for shared-secret situations — it is not a replacement for real authentication, per-user permissions, or encryption. Anyone who has both the link and the password gets in, and people can forward both. There’s no per-person audit trail and no way to cut off one recipient without cutting off everyone (by changing the password).
For regulated data, contracts with real legal exposure, or anything where you need to know exactly who accessed what and when, use a proper document platform with per-user auth. For everything lighter — which is most day-to-day sharing — the password link is the right amount of lock.
Share the password on a separate channel
One habit multiplies the protection: send the link and the password through different channels. Link in the email, password in the Slack DM. Link on the slide, password said out loud. If either channel leaks — a forwarded email, a screenshotted chat — the leak alone isn’t enough to open the door. Posting the link and the password in the same message reduces the gate to decoration.
Creating one on 302.sh
Password protection is available on the Creator plan ($9/mo) and above. Creating a protected link takes under a minute:
- 1. Create a new link from the dashboard and paste your destination URL as usual.
- 2. Open the Password section of the form and type the password you want visitors to enter.
- 3. Create the link and share it. Visitors now see the password page first; correct entry sends them through.
The password is editable for the life of the link: add one to an existing public link when circumstances change, rotate it when a review round ends, or remove it entirely once the content goes public — the short URL itself never changes, so nothing needs to be re-shared or reprinted.
Password protection also stacks with the rest of the link toolbox. Add an expiry date to make a sensitive share die on Friday whether or not anyone remembers to clean it up, or a click limit to cap how many times the gate can be opened at all. And because every 302.sh link is served as a temporary 302 redirect, you can repoint the destination at any time without touching the password or the short URL.
Frequently asked questions
What does a visitor see when they open a password-protected link?
Instead of redirecting immediately, the short link shows a small password page hosted on 302.sh. The visitor types the password, and on a correct entry they are sent straight to the destination. There are no accounts to create and nothing to install — one field, one secret, done.
Can someone find the destination URL without the password?
No. The destination URL is never exposed until the correct password is entered — it does not appear in the password page’s source code or in any redirect header. Verification happens server-side, and 302.sh stores only a hash of the password, never the password itself.
Can I change or remove the password later?
Yes. You can add, change or remove the password at any time by editing the link, and the short URL itself never changes. That means you can rotate the password after a client review wraps up, or drop it entirely once the content goes public.
Is a password-protected link secure enough for confidential documents?
Treat it as lightweight access control, not a vault. Anyone who has both the link and the password gets in, and either can be forwarded. For regulated data, per-user permissions, or anything requiring an audit trail, use real authentication and encryption. Password links are for shared-secret situations: previews, replays, embargoes and similar one-off shares.