Encrypted Pastebin: How Zero-Knowledge Paste Sharing Actually Works

The three things "encrypted" can mean

When a paste service says "encrypted," it could mean one of three completely different architectures with very different threat profiles. Conflating them is the single most common mistake in this space, including by writers who should know better.

01 Encrypted in transit (TLS / HTTPS)

The browser-to-server connection uses TLS. Every modern website does this; it's table stakes. It protects against someone sniffing your traffic on hotel WiFi or your ISP reading the wire. It does nothing to protect your paste once it reaches the server. The operator decrypts it the instant it lands.

02 Encrypted at rest (server-side encryption)

The server stores your paste using disk-level or column-level encryption — typically AES-256 with a key managed by AWS KMS or similar. This protects against someone stealing the hard drive or a backup tape. It does nothing to protect against the operator: the application has the key, so any database query, any debug log, any compelled disclosure exposes plaintext. Most "encrypted pastebins" mean this.

cloakbin

03 Zero-knowledge (client-side encryption)

The paste is encrypted in your browser before any network request happens. The key is generated locally and never sent to the server — it lives only in the URL fragment, which browsers refuse to transmit. The server only ever sees ciphertext. Even with full root access to our database, even under subpoena, even if a rogue employee dumps everything to a USB stick — the data is mathematically indecipherable without the key. This is what CloakBin does.

Threat model: who can actually read your paste

The honest way to evaluate any "secure" paste tool is to enumerate every party in the system and ask: can they read my plaintext? Here is that table for each of the three models above, plus a plain Pastebin.com baseline. Hover any cell to crosshair its row and column.

actor × model	Plain Pastebin.com	TLS only in transit	At rest server-side	Zero-knowledge CloakBin
You (the sender)	Yes	Yes	Yes	Yes
Intended recipient (with link)	Yes	Yes	Yes	Yes
Network attacker (coffee-shop WiFi, ISP)	Yes	No	No	No
Service operator / employee with DB access	Yes	Yes	Yes	No
Cloud host (AWS, GCP, hypervisor)	Yes	Yes	Often	No
Subpoena / law enforcement request	Yes	Yes	Yes	No (only ciphertext)
Database breach / leaked backup	Yes	Yes	Sometimes	No
Rogue admin tampering with frontend	Yes	Yes	Yes	Possible — see limits

Note the bottom row: zero-knowledge does not magically defeat a malicious operator who controls the JavaScript bundle delivered to your browser. We address this in the limitations section below — pretending otherwise would be dishonest.

What actually happens when you create a paste

This is the full lifecycle, simplified but accurate. If you've read this far you probably want to see the moving parts, not a marketing diagram.

step 01

Browser generates a 256-bit key

crypto.getRandomValues() produces 32 cryptographically random bytes via the OS CSPRNG. No JavaScript random, no Math.random.
step 02

Content is encrypted with AES-256-GCM

The Web Crypto API encrypts your plaintext with a random 96-bit IV. GCM produces a 128-bit authentication tag that catches any tampering with the ciphertext. All of this runs in the browser, in native code, not in JavaScript.
step 03

Ciphertext (and only ciphertext) is POSTed

The request body contains the encrypted bytes, the IV, expiry settings, and metadata like burn-after-read. The key is not in the request. Our server stores the blob in MongoDB and returns a short ID.
step 04

Browser composes the share URL

You get cloakbin.com/abc123#. The part after # is the URL fragment. Per RFC 3986, browsers don't include fragments in HTTP requests, so the key is never logged by us, our CDN, our cloud provider, or any analytics pixel.
step 05

Recipient decrypts in their own browser

They open the link, the page JavaScript reads the key out of window.location.hash, fetches the ciphertext, and decrypts locally. The plaintext exists only in their tab. If burn-after-read is on, the server deletes the record immediately on first GET.

What this is good for — and what it isn't

Encrypted pastebins are excellent for short-lived secret hand-off. They are bad at archival, search, collaboration, and anything requiring proof-of-content over time. Honest fit matters more than marketing-speak about "any sensitive data."

use-for.diff Use it for

API keys, OAuth tokens, and short-lived secrets you must hand to a teammate
Database connection strings during incident response
.env files for a new dev environment
Recovery phrases, SSH keys, signed certificates
One-off code snippets you don't want indexed by Google or AI scrapers
Whistleblower documents where server compromise must not reveal content

dont-use-for.diff Don't use it for

Anything you must legally retain — a lost URL means lost data, by design
Audit logs or compliance evidence (use append-only storage with a chain of custody)
Files larger than your plan's ciphertext limit (10MB on Premium, 500KB free)
Long-form documents you want collaborators to edit (use a real doc editor)
Public, indexable content — fragments aren't crawlable, so search won't find it
Content that needs server-side search — we literally cannot index ciphertext

Limitations we won't hide

Every zero-knowledge web tool has the same set of caveats. Vendors who skip this section are either uninformed or hoping you are. Here's the honest list.

! 1. We could push malicious JavaScript

Since the crypto runs in code we serve, a compelled or compromised operator could deploy a tampered bundle that exfiltrates plaintext before encryption. This is the fundamental browser-crypto limitation — true for ProtonMail, Bitwarden web, Standard Notes web, and every other zero-knowledge web app. Mitigations: open source, SRI hashes, and self-hosting for adversarial threat models.

! 2. Metadata is still visible to us

We see paste size, creation time, IP address (for rate-limiting, retained briefly), and expiry settings. We cannot see content, language, or recipient. If your threat model includes traffic analysis, route through Tor.

! 3. Lost URL = lost data, no recovery

We have no key escrow. Lose the link, lose the paste — there is no support ticket that fixes it. This is a feature, but it's also a real failure mode users encounter.

! 4. URL leaks defeat the whole system

If you paste the full link including the fragment into a chat tool that previews URLs, some bots fetch the page on the server side and the fragment may end up in their logs. Worse, if a server-side preview bot ever executes the JS, it could trigger a burn-on-read deletion before your recipient opens it. Send links via channels that don't unfurl, or password-protect the paste.

! 5. We rely on the browser's crypto being correct

Web Crypto is implemented by Chromium, Firefox, and Safari. A bug in any of those (historically rare but not zero) would affect us. We've made the deliberate choice not to ship our own crypto in JavaScript, because hand-rolled JS crypto is worse than trusting battle-tested native code.

CloakBin vs other paste tools

Feature	CloakBin	Pastebin	PrivateBin	Defuse
Encryption in browser (zero-knowledge)
AES-256-GCM (authenticated encryption)
Burn after first read
Password-gated decryption (extra key)
Syntax highlighting (50+ languages)
Custom URLs (vanity slugs)
Anonymous (no signup)
Programmatic API

PrivateBin is the closest spiritual cousin and we recommend it if you want to self-host. CloakBin is what we'd build if we were running it as a hosted service with developer ergonomics — syntax highlighting for 50+ languages, vanity URLs, an API, and a paid tier that funds the infrastructure honestly so we don't have to mine your data.

What you get on CloakBin

Zero-knowledge encryption

AES-256-GCM via Web Crypto, key in URL fragment, ciphertext-only on the server.

Burn after read

Hard delete on first successful GET — the row is gone, not flagged.

50+ languages

CodeMirror 6 syntax highlighting — applied after decryption, locally.

Anonymous by default

No signup to create or read. Accounts only unlock paid features.

Honest answers to the questions people actually ask

01 What's the actual difference between zero-knowledge and "encrypted"?

Most products that advertise "encrypted" use TLS in transit and AES at rest — meaning the server decrypts your data the moment it arrives and the moment it leaves. The operator can always read it. Zero-knowledge means the key never reaches the server in the first place. CloakBin stores ciphertext we cannot decrypt, even if we wanted to.

02 If the key is in the URL, isn't that just security through obscurity?

No. The fragment portion of a URL (everything after #) is defined by RFC 3986 as client-side state — browsers do not transmit it in HTTP requests. Web servers, CDNs, proxies, and analytics tools never see it. A 256-bit key in the fragment has the same secrecy properties as a 256-bit key in any other channel: it depends on you sharing the URL carefully.

03 Could CloakBin push malicious JavaScript and steal my plaintext?

Yes — that's the honest limit of any web-based zero-knowledge tool. We could theoretically push a tampered script that exfiltrates plaintext before encrypting it. This is true of every browser crypto app (ProtonMail, Bitwarden web, Standard Notes web). Mitigations: our source is open, Subresource Integrity hashes guard third-party scripts, and high-stakes users should self-host or use signed native clients. Honesty is more useful than marketing here.

04 Why AES-256-GCM specifically?

GCM is an authenticated encryption mode — it detects tampering with the ciphertext. Older "encrypted pastebins" using AES-CBC without an HMAC can be silently flipped bit-by-bit by an attacker who controls the server. GCM produces an authentication tag with every paste, so any modification fails decryption visibly. The Web Crypto API ships GCM in every modern browser, so no JS crypto library is involved.

05 What happens if I lose the URL?

The paste is unrecoverable. There is no "forgot password" flow because there is no password we hold. This is the whole point — but it means you should treat the link the way you treat the secret itself.

06 Is this better than Pastebin.com for code?

For sensitive code, yes — Pastebin.com stores plaintext and has been the source of repeated leaks (12M+ credentials found by scrapers in 2023). For public code you want indexed, Pastebin is fine and CloakBin is the wrong tool (we can't index ciphertext, so search engines won't find your encrypted paste).

07 How does CloakBin compare to PrivateBin?

PrivateBin is the closest analog and a respected open-source project. PrivateBin requires self-hosting for the strongest guarantees and lacks features like syntax highlighting for 50+ languages, vanity URLs, and a hosted API. CloakBin trades some self-host purity for a working hosted product with the same zero-knowledge architecture.

$ exit --try-it

Try it once and decide for yourself

No signup. Open the editor, paste something throwaway, watch the URL come back with a fragment, and read this article again with the actual artifact in front of you.

Create Encrypted Paste