Security Architecture

How SnapPwd turns a secret into a one-time handoff without storing the decryption key.

Zero-Knowledge Architecture

SnapPwd is designed as a delivery layer, not a vault. The server can store and delete encrypted payloads, but it cannot decrypt them because the key is generated in the browser and carried client-side.

Encrypt in the browser

Secrets and files are encrypted locally before upload. The API receives encrypted payloads, not plaintext.

Keep the key in the URL fragment

The decryption key is placed after # in the share URL. Browsers do not send that fragment to the server.

Wait for a human reveal

Opening the link loads a reveal screen first. The payload is fetched and deleted only after the recipient clicks reveal.

Delete after reveal or expiry

One-time payloads are removed after successful retrieval, or automatically expire after the selected time window.

How It Works

1

Encrypt

Your browser generates a random key and encrypts the secret or file with AES-GCM.

2

Store encrypted data

SnapPwd stores the encrypted payload and metadata needed to deliver it, but not the decryption key.

3

Reveal once

The recipient clicks reveal, decrypts locally in their browser, and the encrypted payload is deleted.

Scanner-Safe Reveal

Link previews and many safe-link scanners can open a URL before a human sees it. SnapPwd avoids burning the one-time payload on page load. The encrypted data is fetched and deleted only after the recipient clicks the reveal button.

Limit: a tool that executes JavaScript and clicks reveal can still consume a link. SnapPwd makes passive previews safer; it does not make a forwarded link private.