Password Protected Short Links

What is a password protected link?

A password protected link is a URL that doesn't redirect until the visitor enters a password you chose. The destination is hidden behind a small zip1.io page that prompts for the password, hashes the input, and only sends the visitor onward if it matches.

It's the right primitive when you want to share a URL publicly — in a Slack channel, a tweet, an email thread, a CMS — but you don't want every reader of that channel to follow it. The password becomes the access token, and you share it through a separate channel (or in person).

Make one in five seconds

Web form: paste your URL on zip1.io, click "Advanced Options", type a password into the Password field, and click Shorten.

API (no key required, 10 requests/min per IP):

curl -X POST http://zip1.io/api/create \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-site.com/private-doc",
    "password": "correcthorsebatterystaple"
  }'

# Response:
# {"short_url": "http://zip1.io/xK9p3z", ...}

Passwords must be at least 8 characters. The first time the short URL is opened, the visitor sees a password page. After they submit the correct password, they're redirected to the destination — exactly as written, with query string and fragment preserved.

How the security works

Most "password protected link" tools take one of two approaches. zip1.io takes the more conservative one:

• Server-side bcrypt hashing. Your plaintext password never leaves the request that created the link — we hash it with bcrypt before writing to the database. The hash can verify a guess; it cannot reproduce the original password. Operators can't recover a forgotten password from the database, and a database leak doesn't expose passwords in plaintext.
• The destination URL stays on our server. The password gates the redirect. It does not encrypt the destination. If an attacker compromises our infrastructure, they can read destinations directly. For threats at that level, use a zero-knowledge tool (OneTimeSecret, Privatebin) instead — see the FAQ.
• The password is not in the URL. Some tools (Link Lock, parts of Rebrandly's flow) embed the password — or the AES key derived from it — into the URL fragment. That makes the URL itself self-contained, but anything that captures the URL captures the password too. zip1.io's password is server-side only; the URL alone is useless without it.

Stack with expiry and click caps

The password field is independent from max-clicks and expiration-time, so you can combine them freely. Three patterns we see in production:

{
  "url": "https://staging.example.com/preview/abc",
  "password": "client-preview-2026",
  "max-clicks": 1
}

{
  "url": "https://docs.example.com/q1-deck",
  "password": "thursday-meeting",
  "expiration-time": "2026-04-28T17:00:00Z"
}

When to use a password protected link

• Client previews — share a Figma comment link, a Loom recording, or a staging URL with a single client without making it crawlable.
• Investor data rooms — a dated deck, a financial model, an investor update, behind a one-shot password.
• Beta / early access — a public landing page protected by a single password you give cohort members. Pair with click analytics to see who actually opened it.
• Internal docs in a public channel — when the channel is shared but the doc is not, the password is the boundary.
• Sensitive forwards — invoices, contracts, signed PDFs hosted on your own file system; the short link gives you an access layer the file host doesn't.

How zip1.io compares to other password-link tools

Comparison reflects publicly documented features at time of writing. Vendor terms change — check current pricing pages for the latest.

FAQ

• What's the minimum password length?

  8 characters. Anything shorter is rejected by the API with a 400 response.

• Can I change or remove the password later?

  Not currently — links are immutable once created. If you need to rotate a password, mint a new short link with the new password and re-share. The old link's stats remain accessible at http://zip1.io/stats/<slug>.

• Is this end-to-end encrypted?

  No. zip1.io stores the destination URL in plaintext on the server so it can perform the redirect after the password check. The password gates access; it does not encrypt the destination. For zero-knowledge secret sharing, use a dedicated tool like OneTimeSecret or Privatebin.

• How does this differ from Link Lock or in-browser AES tools?

  Link Lock-style tools embed the AES key (derived from the password) into the URL fragment, so the password never reaches a server. zip1.io takes the opposite trade-off: the password is hashed on our side, never embedded in the URL, so anyone who only captures the URL still needs the password to use it. Both are valid; pick based on which trust model fits.

• Will Slack / iMessage previews unlock the link?

  No. Preview bots see the password page, not the destination. They may consume a click against your max-clicks cap if you set one, but they can't bypass the password.

Related