Secure Password Share

How do you share a password securely with an encrypted link?

Type the secret into Secure Password Share and it is encrypted in your browser with AES-256-GCM. The encrypted payload is packed into the link’s URL fragment (the part after #), which browsers never send to any server — so the secret is never uploaded. Send the link over a private channel; in passphrase mode, send the passphrase over a different channel. Everything runs 100% client-side with no backend.

AES-256-GCM authenticated encryption via the Web Crypto API — random key or PBKDF2-HMAC-SHA-256 passphrase
The ciphertext travels in the URL #fragment, which is never transmitted to a server
Random-key mode opens instantly; passphrase mode keeps the key out of the link as a second factor
Recipient reveals and decrypts locally, with copy-and-clear and a per-device viewed flag
Honest: with no backend this is not a true one-time / burn-after-read secret

What is

Encrypted secret-sharing link

An encrypted secret-sharing link is a URL that carries an end-to-end encrypted secret so a recipient can decrypt it without the sender storing it on a server. This tool encrypts the secret in the browser with AES-256-GCM and places the entire ciphertext in the URL fragment (after the # symbol), which browsers never include in the HTTP request — achieving a zero-knowledge, no-backend design similar to PrivateBin. In random-key mode the decryption key is embedded in the link; in passphrase mode the key is derived from a passphrase with PBKDF2 and is never in the link. Because there is no backend, it cannot enforce true burn-after-read or expiry.

Security & Privacy

Related terms

AES-256-GCMWeb Crypto APIPBKDF2URL fragmentzero-knowledgeend-to-end encryptionPrivateBinone-time secretburn after readingbase64url

Frequently Asked Questions

Encryption happens entirely on your device with the browser’s Web Crypto API. The encrypted payload is stored in the URL fragment — the part after the # — which browsers do not include in the HTTP request, servers and proxies do not log, and the Referer header strips. There is no backend, database, upload or CDN in the crypto path, and no analytics; the secret lives only in the link and your clipboard.

No. The secret is encrypted in your browser and the ciphertext rides in the URL fragment, which is never sent to a server.

A real burn-after-read secret needs a server to store the ciphertext and delete it after the first fetch. This tool has no server, so the encrypted secret lives inside the link itself and keeps working every time the link is opened. The “viewed” flag is stored in your browser only and cannot stop someone opening the same link on another device. For guaranteed one-time access and expiry, use a hosted service such as onetimesecret.com or a self-hosted PrivateBin.

No. With no backend it cannot burn after reading — anyone with the full link can open it until you delete it where you shared it.

In random-key mode a fresh 256-bit AES key is generated and packed into the link alongside the ciphertext, so anyone with the full link can open it — treat the whole link as the secret. In passphrase mode the key is derived from a passphrase with PBKDF2-HMAC-SHA-256 and only the ciphertext is in the link; the recipient must also enter the passphrase, which you send over a different channel. A leaked passphrase-mode link alone cannot be decrypted.

A random-key link embeds the key (opens instantly); a passphrase link keeps the key out of the URL as a second factor.

Use a private, trusted channel for the link (not a public post), and in passphrase mode send the passphrase through a different app or medium so a single intercepted message is not enough. Delete the message once the recipient has retrieved the secret, since the link keeps working. Be aware that URLs can be cached in browser history, chat link previews and security scanners, so treat the link as sensitive.

Send the link over a private channel and, in passphrase mode, send the passphrase over a separate channel; delete both after use.

A 100% client-side encrypted secret-sharing tool that encrypts a password, API key or note in the browser with AES-256-GCM (random key or PBKDF2 passphrase) and packs the ciphertext into the URL fragment — never sent to a server — producing a self-contained link with a copy button and QR, a local reveal-and-decrypt view with copy-and-clear, and a per-device viewed flag. It is honest that, with no backend, it is not a true burn-after-read secret.

Features

AES-256-GCM authenticated encryption via the Web Crypto API; all randomness from crypto.getRandomValues
Random-key mode (key embedded in the link) and passphrase mode (PBKDF2-HMAC-SHA-256, key never in the link)
The ciphertext rides in the URL #fragment, which browsers never transmit to a server
Recipient reveal view with show/hide, copy-and-clear, a QR of the link, and a per-device viewed flag
Prominent honest note: no backend means no true one-time / burn-after-read or server-side expiry

PriceFree

CategorySecurity & Privacy

PlatformAll (any modern browser with the Web Crypto API)

PrivacyThe secret is encrypted entirely on your device and the ciphertext is stored only in the URL fragment, which browsers never send to a server; there is no backend, upload, database, logging or CDN in the crypto path, and no analytics. The secret lives only in the link and clipboard, the tool works offline once cached, and the only optional network use anywhere on the site is consent-gated ads, which never see your secret.

Input: Any text secret pasted into the tool (password, API key, recovery code, note), A Secure Password Share link pasted in to reveal

Output: A self-contained encrypted share link (copy), A scannable QR code of the link (download PNG)

Detailed Explanation

How It Works

What This Tool Does

Secure Password Share is a 100% client-side tool for sending a secret — a password, API key, recovery code or private note — as an end-to-end encrypted link. A pure engine (secretShareEngine.ts) encrypts the secret in the browser with AES-256-GCM and packs the whole ciphertext into the URL fragment (the part after #), which browsers never send to a server. The recipient opens the link and decrypts it locally. There is no backend, no upload and no database; the link itself is the encrypted message.

Encrypts a secret in the browser with AES-256-GCM (Web Crypto API)
The encrypted payload rides in the URL #fragment, never transmitted to a server
Self-contained: the link carries everything needed to decrypt
Recipient decrypts locally with reveal, show/hide and copy-and-clear
No backend, no upload, no CDN in the crypto path

Methodology

How the Two Modes Work

In random-key mode the engine generates a fresh 256-bit AES key with crypto.getRandomValues, encrypts the secret with AES-256-GCM under a random 12-byte IV, and base64url-encodes iv ‖ rawKey ‖ ciphertext+tag into the fragment as #s1k.… — so the link opens with no passphrase. In passphrase mode it reuses the audited textCryptoEngine: PBKDF2-HMAC-SHA-256 stretches the passphrase over a random salt into the AES key, and only version ‖ iterations ‖ salt ‖ iv ‖ ciphertext+tag is placed in the fragment as #s1p.… — the passphrase is never in the link. GCM is authenticated, so a wrong key or any tampering fails to decrypt.

Random-key: #s1k.base64url(iv ‖ 256-bit key ‖ ciphertext+tag)
Passphrase: #s1p.base64url(version ‖ iterations ‖ salt ‖ iv ‖ ciphertext+tag)
PBKDF2-HMAC-SHA-256 key stretching; iteration count stored in the payload
AES-GCM authentication tag detects tampering or a wrong passphrase
base64url (RFC 4648 §5) keeps the payload URL-safe

Technical Details

Why the URL Fragment Is Private

A URL fragment (everything after #) is a client-side construct: it is not included in the HTTP request line, so web servers, reverse proxies and the AnyTool host never receive or log it, and modern browsers strip it from the Referer header sent to third parties. This is the same zero-knowledge property PrivateBin relies on, where the server stores only an opaque blob and the key stays in the fragment. Here there is no server at all: the ciphertext and (in random-key mode) the key live only in the fragment, so nothing is uploaded and the tool works fully offline once cached.

Fragments are never part of the HTTP request — servers cannot log them
Stripped from the Referer header sent to other origins
Same fragment-key model as PrivateBin, but with no backend at all
Works offline once the page is cached (PWA)
All randomness from crypto.getRandomValues — never Math.random

Limitations

Honest Limitations

This is end-to-end encrypted but it is not a true one-time or self-destructing secret. Because there is no backend to store and delete the ciphertext, anyone holding the full link can open it repeatedly until the sender deletes it from wherever it was shared, and the tool cannot enforce server-side expiry. The “viewed” flag is stored on the opening device only and cannot prevent a different device from opening the same link. URLs may also be retained in browser history, chat link previews and security scanners. In random-key mode the key is inside the link, so a leaked link is a leaked secret; passphrase mode adds a second factor but relies on the passphrase being shared over a different channel. For guaranteed burn-after-read and expiry, use a hosted service such as onetimesecret.com or a self-hosted PrivateBin.

No backend → no true burn-after-read and no server-side expiry
Anyone with the full link can decrypt it repeatedly
The “viewed” flag is per-device only, not a global lock
Links can be cached in history, previews and scanners
Random-key links: the link itself is the secret — share privately

Privacy & Security

Private by Design

The secret is encrypted entirely on the user’s device with the browser’s Web Crypto API, and the ciphertext is stored only in the URL fragment, which is never sent to a server. There is no upload, no database, no logging, no server and no CDN in the crypto path, and no analytics or telemetry anywhere in the tool. The secret exists only in the link and, briefly, the clipboard; the reveal view offers a copy-and-clear action and can strip the link from the current tab. The tool works offline once cached, supports dark mode and a mobile-first layout, and the only optional network use anywhere on the site is consent-gated ads, which never see the secret.

Encryption runs locally — nothing uploaded, logged or stored on a server
Ciphertext lives only in the #fragment and the clipboard
No server, no CDN, no analytics in the crypto path
Copy-and-clear and a strip-from-tab action for the recipient
Works offline once cached; dark-mode and mobile-first

Random-key vs passphrase links
Aspect	Random-key link (#s1k)	Passphrase link (#s1p)
Opens with	Just the link (key embedded)	Link plus the passphrase
Key derivation	Random 256-bit AES key	PBKDF2-HMAC-SHA-256 from the passphrase
If the link leaks	The secret is exposed	Still safe without the passphrase
What to share separately	Nothing — the link is the secret	Send the passphrase over a different channel
Best for	Speed and convenience	Higher-stakes secrets needing a second factor

Both modes are AES-256-GCM and 100% client-side. Neither is a true burn-after-read secret — there is no backend to delete the ciphertext. As of July 2026.

Cite This Page

Title: Secure Password Share
Author: AnyTool
Published: January 1, 2026
Modified: February 8, 2026
Section: Security & Privacy
URL: https://www.anytool.tech/secure-password-share

Formatted Citation

AnyTool. "Secure Password Share." AnyTool, January 1, 2026. https://www.anytool.tech/secure-password-share

A 100% client-side encrypted secret-sharing tool — the /secure-password-share route in the AnyTool Security & Privacy category — that lets a sender share a password, API key, recovery code or private note as an end-to-end encrypted link with no backend, no upload and no CDN in the crypto path. A pure, fully-typed engine (secretShareEngine.ts) encrypts the secret in the browser with AES-256-GCM via the Web Crypto API and packs the entire ciphertext into the URL fragment (the part after #), which browsers never include in the HTTP request, servers and proxies never log, and the Referer header strips — the same zero-knowledge fragment-key property PrivateBin relies on, but with no server at all. Two modes are offered. In random-key mode a fresh 256-bit AES key is generated with crypto.getRandomValues, the secret is encrypted under a random 12-byte IV, and iv ‖ rawKey ‖ ciphertext+tag is base64url-encoded (RFC 4648 §5) into the fragment as #s1k.…, so the link opens instantly without a passphrase and the whole link is effectively the secret. In passphrase mode the engine reuses the audited textCryptoEngine: PBKDF2-HMAC-SHA-256 stretches the passphrase over a random 16-byte salt (default 210,000 iterations, adjustable toward the OWASP ≥600,000 guidance, with the count stored in the payload) into the AES-256 key, and only version ‖ iterations ‖ salt ‖ iv ‖ ciphertext+tag is placed in the fragment as #s1p.… — the passphrase is never in the link, adding a second factor the sender shares over a different channel. GCM authentication means a wrong key, wrong passphrase or any tampering fails closed. The sender UI offers a mode selector, a secret textarea with a cryptographically-random secret generator and a byte/character count, a passphrase field with a strength meter and an advanced PBKDF2 iteration slider, and produces a self-contained link with its character length and a truncation warning past ~2000 characters, a copy button, and a scannable QR of the link (rendered locally via the shared qrEngine, downloadable as PNG) with an honest message when the link is too long to fit. When the page loads with a payload in the hash, or when a link is pasted into the reveal box, it detects the mode, prompts for the passphrase if needed, and decrypts locally into a reveal view with show/hide, copy-and-clear, a strip-from-tab action, and a per-device viewed flag (a SHA-256 fingerprint of the fragment stored in localStorage) that hides the secret after the first open on that device only. The page follows the golden design system: a custom SecureShareIcon (a teal URL pill marked with a white hash, a coral share node, and a gold padlock with a white keyhole) in the header and a feature card, exactly four trust badges (100% client-side / Nothing uploaded / AES-256-GCM / Free forever), three feature cards, AEO and GEO sections, exactly three horizontal ad slots (secure-password-share-top / -mid / -bottom) and a sticky mobile action bar (Reveal or Copy plus New/Reset), with full dark-mode and mobile-first responsive support. It is scrupulously HONEST that, because there is no backend, it is end-to-end encrypted but NOT a true one-time or self-destructing secret: anyone with the full link can decrypt it repeatedly until the sender deletes it from wherever it was shared, there is no server-side expiry, the viewed flag is per-device only, and links can persist in browser history, chat previews and security scanners — for guaranteed burn-after-read and expiry it explicitly points users to a hosted service such as onetimesecret.com or a self-hosted PrivateBin, and it advises sending the link and (in passphrase mode) the passphrase over different channels. Privacy is structural: the secret is encrypted locally, the ciphertext lives only in the #fragment and briefly the clipboard, all randomness comes from crypto.getRandomValues rather than Math.random, there is no upload, database, logging, server, CDN or telemetry in the crypto path, the tool works offline once cached, and the only optional network use is consent-gated ads that never see the secret.