Security · Last reviewed October 2026
Private mode encrypts your text or file contents in the browser with a key our servers never receive. Standard shares are encrypted in transit and at rest. Here is exactly how both work, what we store, and what we cannot see.
Two modes
Same tool and the same 5-character code. Ticking “Encrypt Now” adds a layer where the decryption key never reaches our servers.
The code works on its own. Content is encrypted in transit and at rest, and deleted when its read limit or timer is reached.
Your browser encrypts the text before it is uploaded. We store ciphertext we cannot read — the key exists only in the link you share.
Private mode
Four steps, all of them in your browser. The server never receives the plaintext or the key.
01
Your browser creates a random 256-bit key using the Web Crypto API. It never leaves the device.
02
AES-256-GCM encrypts the text locally. GCM also authenticates it, so a wrong key fails loudly instead of showing garbage.
03
The encrypted blob and metadata go to our server. The key goes into the link after the # symbol — a part browsers never transmit.
04
Their browser reads the key from the link, fetches the ciphertext, and decrypts it locally. The content is then deleted on schedule.
With the optional Pro passphrase, the AES key is derived with HKDF from the link key and a PBKDF2 mix of your password (210,000 iterations). We store only a SHA-256 hash of that mix — never the mix itself — so a database dump plus a leaked link still cannot decrypt the text.
Visibility
No vague promises — here is the honest table, mode by mode.
| Share type | What our server stores | Can we read it? |
|---|---|---|
| Standard text | AES-256-GCM ciphertext at rest; decrypted at request time | Yes — to deliver it |
| Private text | Ciphertext only; the key never reaches us | No |
| Private text + passphrase | Ciphertext plus a salted hash of the key mix | No — even with the database |
| Standard files | File bytes on an access-controlled server, scanned before serving | Yes — for scanning and serving |
| Private files | Ciphertext only; the key never reaches us. Names, types, sizes, and paths remain visible | No |
| API / MCP text | Standard-mode ciphertext at rest | Yes — while processing |
API and MCP shares are created server-side, so they always use Standard mode. Every share — private or standard — also stores metadata: the code, timestamps, expiry, read counts, and file sizes.
Retention
We delete content on a timer or on read, and we do not keep backups of it.
| Data | Retention |
|---|---|
| Text shares (standard and private) | Deleted at the read limit or when the timer ends — 10 minutes to 30 days, or never if the sender chooses |
| Files | Standard: deleted after download. Private: deleted after download + decryption acknowledgement. Either way, also when the timer ends (10 minutes to 30 days) |
| Pro receipts | Event times only (no IP or content) — 90 days after a share closes; never-expiring shares keep a one-year window |
| Security events | Event type, share code, and timestamp — 7 days |
| Server logs | IP address and timestamp — up to 7 days |
| Content backups | None — we do not back up shared text or files |
Private links
A 5-character code has about 33 million possible values. If the code were also the decryption key, anyone who obtained the stored ciphertext could try every combination offline in minutes. That would defeat the point of encryption.
So the key travels in the part of the link after the #. Browsers never send that part to any server — it stays between the sender and the recipient. The trade-off is simple: a Private share must be opened with the full link, not just the code. When the toggle is on, the result card shows only the link.
If someone types only the code, we stop before fetching anything, so the share is not consumed. Ask the sender to copy the full link (or use the QR code) instead.
Protections
HTTPS on every page and API call, with HSTS so browsers refuse to fall back to plain HTTP.
Every endpoint is rate-limited per IP — for example 10 shares per minute and 20 reads per minute. Code enumeration is not practical.
Ten wrong passwords within 15 minutes permanently deletes the share, so guessing destroys the target instead of unlocking it.
Passwords are derived in the browser with PBKDF2-HMAC-SHA256 (210,000 iterations). Private-mode shares store only a hash of the key mix.
Content-type sniffing, framing, referrer leaks, and unnecessary browser permissions are blocked at the edge.
No wildcard CORS. License keys are hashed in storage, Pro sessions use signed http-only cookies, and ownership is checked on every delete or receipt request.
Files
Private file mode
Turn on “Encrypt files” and the browser encrypts the contents with AES-256-GCM before upload; the key stays in the link after the # and never reaches us. File names, MIME types, sizes, and folder paths remain visible. Encrypted contents cannot be virus-scanned, so only open files from people you trust. Standard uploads are scanned. Encrypted transfers download one file at a time because the server cannot build a plaintext ZIP. Lose the link and the file cannot be recovered.
Verify it yourself
You can check the important claims with browser developer tools, no account needed.
1. Watch the request
Open DevTools → Network, create a Private share, and inspect the POST /api/share body. It contains ciphertext (ct) and metadata — never your text or the key.
2. Look at the address bar
The key is after the # in the share link. Fragments are never included in HTTP requests, so no server, CDN, or log receives it.
3. Read it once
Open the full link in a private window, read the text, then reload. A single-use share is gone — the ciphertext was deleted after the first read.
4. Check the headers
Responses carry HSTS, X-Content-Type-Options: nosniff, frame denial, a referrer policy, and a restrictive permissions policy.
Found a flaw, or think a claim on this page is wrong? Email aghazain10@gmail.com with the subject “Security report”. Include the steps to reproduce it. We read every report and will not take legal action against good-faith research.
Keep sensitive findings out of public posts until we have had a chance to fix them. There is no paid bounty program, but we are happy to credit responsible reports.