BurnChat Now Has End-to-End Encryption 🔐
One command. That's all it takes. Type /e2e in any room and every message is encrypted in your browser before it reaches the server. The server relays encrypted blobs it can't read. No one can — except the people in the room with the key.
How it works
What the server sees vs. what you see
Here's what passes through our server when E2E is enabled:
E2E:nR7kL2mPqX4vB8wY3hT9jF5sA1cD6eG0iK...And here's what you and the other people in the room see:
Hey, want to grab coffee at 3?
The server has no way to decrypt the message. It doesn't have the key. The key exists only in the URL hash, which browsers never send to servers — this is a fundamental rule of how HTTP works. The # fragment stays client-side.
What's encrypted
| Content type | Encrypted with E2E? |
|---|---|
| Text messages | Yes — AES-256-GCM encrypted before sending |
| Private messages (/msg) | Yes — encrypted before relay |
| Voice messages | Yes — audio data encrypted as base64 blob |
| Action messages (/me) | Yes — action text encrypted |
| Announcements | Yes — announcement text encrypted |
| Nicknames | No — needed for room management |
| System messages | No — generated server-side (join/leave/etc.) |
The technical details
We use the Web Crypto API — built into every modern browser. No libraries, no dependencies, no third-party code. The encryption is AES-256-GCM, which is the same standard used by governments, banks, and military communications.
Each message gets a unique 12-byte initialization vector (IV) generated by crypto.getRandomValues(), a cryptographically secure random number generator. The IV is prepended to the ciphertext so the recipient can decrypt. Even two identical messages produce completely different ciphertext because the IV is always different.
The key is shared through the URL hash fragment (#). When you type /e2e, the key is generated and appended to the URL. You share that URL. The recipient's browser reads the hash, imports the key, and starts decrypting. The server never sees the hash — this is how browsers work by specification.
The three layers of BurnChat privacy
With E2E encryption, BurnChat now has three independent privacy layers:
| Layer | What it protects against |
|---|---|
| WSS/TLS encryption | Network sniffing, ISP surveillance, WiFi eavesdropping |
| Zero server storage | Server compromise, data breaches, subpoenas |
| E2E encryption | The server itself — even if compromised, messages are unreadable |
Each layer is independent. Even if one fails, the others still protect you. But when all three work together, the result is a chat system where nobody except the people in the room can read the messages — not us, not hackers, not governments, not anyone.
No setup, no accounts, no key exchange servers
Most E2E encrypted messengers require you to create an account, exchange public keys, verify fingerprints, and trust a key server. BurnChat's approach is radically simpler: the key is in the URL. Share the URL, and you've shared the key. That's the entire key exchange protocol.
Is this as sophisticated as Signal's Double Ratchet algorithm? No. Signal handles long-lived identities, key rotation, and forward secrecy. BurnChat handles disposable rooms where everyone joins, talks, and leaves. Our threat model is different: we're protecting ephemeral conversations, not persistent identities. The simplicity is the feature.
Try it now
Create a room. Type /e2e. Share the URL with someone. Watch the green "E2E encrypted" badge appear. Send a message and know that not even our server can read it.
Your conversation. Your encryption. Your keys.
Type /e2e in any room to enable end-to-end encryption.
Open BurnChat