Basic plan

Password protection

Require viewers to enter a password before accessing your document.

Password protection requires viewers to enter a password before accessing your document. This gate runs before bytes are served—an unverified reader receives no document content, regardless of which link form they use.

How password protection works

When you set a password, it is stored using bcrypt hashing and never stored in plain text. Viewers who enter the correct password receive an unguessable verification token, which is held in their session and keyed to your document's canonical UUID. This means a reader who unlocks the document through one link identifier (short ID, custom slug, or full UUID) automatically remains unlocked when accessing it through any other identifier.

Signed-in owners bypass the prompt on their own documents. That bypass requires a real owner account, so an anonymous (unclaimed) document never treats an anonymous visitor as its owner.

Password protection is a Basic+ feature. Setting a password on a free-tier account is refused server-side with HTTP 403; the control is visible but disabled in the UI.

Passwords are per-document, not per-variant

Passwords apply to the entire document, not to individual link variants. If you share the same document through multiple variant links with different recipients, each recipient who unlocks the document gains access to it through all of its link forms. Link variants can override other settings like download permission or page ranges, but the password gate applies uniformly.

Verification flow

When a reader attempts to view a password-protected document:

  1. They receive a password prompt and enter the password
  2. The backend verifies the password against the stored hash
  3. If correct, the response carries a verification token, and a copy is stored in the reader's session under the document's canonical UUID
  4. On every subsequent request that serves file-derived bytes, the reader presents that token — as an X-Verification-Token header, or as a token query parameter where a header cannot be set — and it must match the session copy
  5. Without a matching token, the viewer receives HTTP 401 and no document content

Expired and burned links are checked before the password, so a dead link reads as dead rather than as password-protected.

What is readable before the password

The password gate withholds document content, not the document's existence. The public metadata endpoint deliberately stays open for a live protected document — the viewer needs it to know that a prompt is required — so anyone holding the link can read the file name, size, page count, viewer mode, and which gates apply before entering the password. Treat the file name as public. Expired, burned, and unclaimed links return an error from that endpoint instead, so it confirms nothing about them.

Embedding and password protection

The embed code is not offered for a password-protected document, and the embedded viewer refuses to render one: it shows a short message with a link to open the document directly instead. An embed is a cross-site iframe, so the session cookie that holds the verification token does not ride its requests, and the gate can never be satisfied inside the frame. The embedded viewer refuses documents with an email gate, a lead-capture form, or a view limit for the same reason.

Expiry and burnout interaction

Password settings cannot be modified after a document has expired or been burned (reached its view limit). Attempts to change settings on an already-dead link return HTTP 410 Gone.

How this differs from email capture

A password proves that a viewer knows a shared secret. An email gate does not prove identity: it collects a self-asserted address, checks it is plausibly formatted (and optionally on an allowed domain), and lets the viewer through — nothing is sent to that address to confirm it. Email capture is a Pro feature and gives you a list of the addresses readers typed; password protection is Basic+ and collects no address at all, though the visit is still recorded as a pseudonymous reader either way. You can combine both: require a password and an email, or neither.

See email gates and lead capture for more.