Frequently asked questions

Your note is encrypted in your browser before anything is sent to us. The browser's native Web Crypto API performs AES-256-GCM with a 256-bit key generated locally by crypto.getRandomValues. The key is placed after the # in the share link — the URL fragment, which browsers never transmit in HTTP requests. The server stores only ciphertext. When the link is opened, the server delivers that ciphertext, deletes it in the same database transaction, and the reader's browser decrypts it locally.

Taken apart properly, with the failure modes that break "one time": the one-time secret link explained. For the fragment specifically: why the key sits after the #.

No. Deletion is part of serving the read: the server removes the note inside the same database transaction that delivers the ciphertext, and every later request returns 404. Recovery is not something we withhold; it is something we cannot do. The decryption key only ever existed in the link and in the browsers at each end — it never reached the server, so even the bytes we briefly stored were unreadable to us.

Exactly one of them gets the note. Burn-after-read is enforced on the server, inside a database transaction that locks the row with SELECT … FOR UPDATE, so simultaneous requests cannot both succeed. We verified this with a test: 8 readers hit a one-view note at the same moment; one received it, the other seven received 404.

The full link is the secret. Anyone who obtains it before it is used can open the note once — so send it over a channel you trust. What network interception does not expose is the key: it sits in the URL fragment after the #, and browsers never transmit fragments, so it cannot appear in server logs, proxy logs or Referer headers. And because reading burns the note, an intended recipient who finds a 404 has evidence that someone else got there first.

We cannot. Encryption and decryption happen in your browser; the server receives ciphertext and nothing else. The AES-256-GCM key is generated by your browser and carried only in the link fragment, which browsers never send in HTTP requests, so it cannot reach the server or its logs. What sits in our database is unreadable to us. AES-256-GCM is also authenticated encryption: tampered ciphertext fails to decrypt rather than returning garbage — we verify this by test, flipping single bits in the body, the tag and the IV.

No. Your browser encrypts the file bytes and, separately, the original filename and MIME type before upload. The server stores the result under a random 32-character hexadecimal name, outside the web root, and a script streams it back while enforcing the expiry and the download counter — there is no directly fetchable URL for the bytes. On our side there is ciphertext with a meaningless name; the real filename reappears only when the recipient's browser decrypts it.

On one point, yes, and we say so plainly: the encryption code is delivered by our server. Whoever controls the server could, in principle, serve altered, key-stealing code to future visitors — and Subresource Integrity and CSP cannot prevent that, because the same server publishes the hashes. Two things limit it. It is forward-looking only: already-encrypted data stays sealed. And it is detectable: the hashes are published at /integrity.json, where they can be archived and compared over time.

Access logging is disabled for this site — the web server is configured not to write one — so no record exists of who read which note. Two honest exceptions. The server's error log still exists and can capture an IP address when a request fails. And rate limiting stores an HMAC-SHA256 of the client IP, keyed with a server secret, truncated, and deleted when its hour-long window closes, so it lives at most an hour plus the minute until the next sweep; the raw IP is never written to the database.

Because data we never collect is data we cannot expose or be ordered to produce. Using this service sets no cookie of any kind, needs no account, runs no analytics and loads no third-party scripts or CDN fonts — a page load fetches only first-party files. The single exception is not yours: the operator's settings page at /admin sets a session cookie, scoped to that path so it is never sent with anything else. The one piece of browser storage is a sessionStorage entry holding the chat display name you typed, and it dies with the tab.

Ciphertext we cannot decrypt: the keys live in link fragments that never reach the server. Access logs of who read what do not exist, because access logging is disabled. The server's error log can hold IP addresses from failed requests, and that is what an order could realistically obtain. The servers are inside the European Union and the data does not leave it. In every case the material is ciphertext we have no way to decrypt.

The note is unrecoverable — by you, by the recipient and by us. The decryption key exists only in the link; it was generated in your browser and never sent to the server, so what remains on our side is ciphertext we cannot open. This is not a defect. A service that could restore your note for you could also read it. If the link is lost, write a new note and share a new link.

Whoever opens the link first reads the note, and reading destroys it. We cannot recall a link once it has been sent, and we cannot see who used it, because access logging is disabled. The design at least makes the mistake visible: if the intended recipient gets a 404, the note was already read, and you should treat the secret as exposed and change it. For anything sensitive, confirm the recipient is ready before you send the link.

Up to 25 MB per file. Before upload, your browser encrypts the file bytes and, separately, the original filename and MIME type, so the server stores only ciphertext under a random 32-character name. The encrypted bytes are kept outside the web root and streamed through a script that enforces the expiry and the download counter. Details are on the files page.

No. There are no accounts, no registration and no email address to give. The service is free, with no paid tier. Open the page, write the note or pick the file, and copy the link it produces — that link is the whole mechanism. Because there is nothing to sign up for, there is also no account data for us to hold.

A chat room lasts only as long as someone has it open. While the room is open your browser checks for new messages every few seconds, and that is what keeps the room alive. When the last person closes the tab nothing refreshes it any more, and the room and every message in it are deleted within about five minutes. Deletion does not wait for a visitor: a cron job runs the expiry sweep every 5 minutes. Messages are stored as ciphertext rows, and the display name you choose is encrypted inside each message, so the server cannot tell who is talking. The name itself lives only in your tab's sessionStorage and disappears when the tab closes.

No, and we do not claim otherwise. Two things narrow the gap between our code and your ability to check it. The frontend is hand-written vanilla JavaScript — no framework, no build step, no minification — so the code your browser receives is the code that runs, readable as delivered. And the integrity hashes for the stylesheet and every script are published at /integrity.json, where they can be archived and compared over time.

Yes. It is an ordinary web page: nothing to install, no account to create. Encryption runs on the browser's built-in Web Crypto API, which current mobile browsers provide, so a note is encrypted on a phone exactly as on a desktop. A page load fetches only first-party files — no third-party scripts, no CDN fonts — which keeps it light on a mobile connection.