A traditional pastebin stores your text in plain form on its servers. Anyone with database access — an employee, a hacker, or a court order — can read everything you've ever pasted. An encrypted pastebin changes the equation: your text is scrambled in your browser before it's ever sent.
When you create a paste, your browser generates a random key and encrypts the content locally. Only the ciphertext travels to the server. The key stays in the link you share, in the fragment after the # — a part browsers never send to servers. The result: the server stores unreadable noise, and only someone with the full link can decrypt it.
Every year, pastebins leak. Developers paste API keys, database credentials, and internal configs into tools that store them in plaintext. A single breach exposes everything. Even "private" or "unlisted" pastes are still readable by the server — and often indexed by search engines anyway.
A real encrypted pastebin should: encrypt client-side (not server-side), never receive your key, and support burn-after-read for secrets that should exist exactly once. If a service can reset your password and show you your pastes, it can read them — and so can anyone who compromises it.
An encrypted pastebin is a text-sharing service where your content is encrypted before it reaches the server — typically inside your browser using the Web Crypto API — so the operator stores only ciphertext. The decryption key is generated locally and embedded in the shareable link's URL fragment (the part after #). Because browsers never send the fragment to a server in an HTTP request, the key never appears in server logs, analytics, or databases. The net effect: the pastebin operator, their hosting provider, and anyone who breaches their database sees only random-looking bytes.
Traditional pastebins work like a public notepad: you send plaintext over TLS, the server decrypts TLS and stores your text in a database, readable to admins, subpoenas, and attackers alike. TLS protects data in transit, not at rest. An encrypted pastebin adds a second layer: the plaintext is turned into ciphertext before TLS even comes into play, using AES-256-GCM — the same authenticated encryption algorithm NIST standardized in FIPS 197 and SP 800-38D, and the same algorithm protecting your banking session. Even a full database dump yields nothing decryptable without the per-paste keys, which live only in the links you chose to share.
Say you paste a database password into Urlpaste. Your browser generates a random 256-bit key, encrypts the text with AES-256-GCM, and uploads the ciphertext to urlpaste.com. The link you copy might be https://urlpaste.com/x7f2q#k9v3.... The fragment #k9v3... is the key in base64. You send that link over Signal to a colleague. Urlpaste's server never saw the key, never logged it, and couldn't decrypt your paste even if compelled to. Your colleague's browser fetches the ciphertext and decrypts it locally. No coffee shop Wi-Fi snooper, no VPN provider, no pastebin admin ever touches plaintext.
Any time the content would cause damage if exposed: API keys, .env files, recovery codes, customer PII, incident notes with internal hostnames, legal documents in draft. The IBM Cost of a Data Breach Report 2024 put the average breach cost at $4.88 million — and a meaningful share of breaches start with poorly handled secrets. An encrypted pastebin with burn-after-read turns "a secret pasted somewhere permanent" into "a secret that existed once, for one reader."
Can the encrypted pastebin operator read my pastes?
No — not in a properly designed zero-knowledge system. Encryption happens in your browser; the server receives and stores only ciphertext, and the key never leaves the URL fragment, which browsers never transmit. The operator would have to break AES-256 to read your content.
Is AES-256-GCM really secure enough?
Yes. AES-256 is approved by NIST and used for classified data; GCM mode adds authentication, so tampering with the ciphertext is detectable. Even against future quantum computers, Grover's algorithm only halves the effective key strength — AES-256 retains ~128 bits of post-quantum security, well above the 112-bit floor NIST considers safe.
What happens if I lose the link?
The paste is unrecoverable — that's the point. Since the key exists only in the link and nowhere else, there is no "forgot my password" flow. Treat the link itself as the secret: share it through a secure channel and store it like a password.