NoteKillnotes that do not survive

Self-destructing notes, files and chat, encrypted in your browser

AES-256-GCM runs in your browser. The key lives only in the link, after the # — browsers never transmit that part, so it cannot reach us, our logs, or anyone in between.

The box above creates a self destructing note — a note that deletes itself after being read. Everything you type is encrypted in your browser before it leaves your device, and the key stays with you. We operate the server, and we cannot read what you write. No account, no email address, no cookies.

How it works

  1. Write your note. Type it in the box above. It exists as plain text only on your device.
  2. It is encrypted in your browser. Your browser generates a random 256-bit key and encrypts the note with AES-256-GCM. Only ciphertext is uploaded to our server.
  3. You get a link with the key after the #. The key sits in the URL fragment, the part of a link browsers never transmit. It cannot reach our server.
  4. The note is destroyed when read. The first person to open the link sees the note, and the server deletes it in the same operation. Anyone who tries afterwards gets a 404.

Burn after reading is enforced on the server, inside a database transaction — not by a script in the reader's browser. We tested it with 8 simultaneous readers of a one-view note: exactly one received the ciphertext, seven received a 404. Expired notes are removed by a cleanup job every minute, not only when someone happens to visit.

The key never leaves your browser

Every share link has two parts, split by the # symbol. The part before it is a normal address: your browser sends it to our server to fetch the ciphertext. The part after it is the URL fragment. Browsers keep the fragment local — it is never included in any HTTP request — and that is where the decryption key lives.

Sent to the server
https://notekill.com/n/8c1de2f04b7a96350d4e6f1a2b3c4d5e

Never transmitted
#Qy7vD2pXk9LmNwEbA5cRfTg8hJ1oUzS4iK6MeGxHnPr

Everything before the # is what our server receives; the identifier is the only meaningful part of it. The 43 characters after it are the 256-bit key, generated on your device by crypto.getRandomValues.

The encryption is AES-256-GCM through the browser's native Web Crypto API — no third-party crypto library. Each encryption uses a fresh random 96-bit IV; in testing, 500 encryptions under one key produced 500 distinct IVs. GCM is authenticated encryption, so a tampered ciphertext fails to decrypt instead of returning garbage: we verified that flipping a single bit in the body, the tag or the IV is always rejected.

What our server actually stores

  • Stored The ciphertext of your note, under a random 128-bit identifier from a CSPRNG.
  • Stored Its size in bytes, its creation time, a view counter and an expiry.
  • Never received The decryption key. It exists only in the fragment, in your browser.
  • Never received The plaintext of your note, at any point, in any form.
  • Never received A readable filename. For shared files, the original name and MIME type are encrypted in your browser along with the file bytes.
  • Never written An access-log entry. Access logging is disabled for this site by configuration, so there is no record of who read which note.

There is little else to hold. No accounts, no registration, no cookies at all, no analytics, no third-party scripts, no fonts from a CDN — a page load fetches only first-party files. The full protections, header by header, are documented at /security.

Can this be intercepted?

The traffic can be captured. It would not give up the note. What crosses the network is ciphertext; the decryption key never does, because it lives in the part of the link after the # symbol, which browsers do not transmit. It cannot appear in our server logs, in proxy logs, or in a Referer header, for the simple reason that it is never sent.

A complete copy of everything our server ever receives for your note would not be enough to read it. An interceptor still learns what any connection reveals — that a browser contacted this host, roughly when, and roughly how many bytes moved — but not a word of what you wrote.

There is also less path to intercept. No CDN, no Cloudflare, no reverse proxy sits between you and us: TLS terminates on the server we run. And a subpoena for our access logs would return nothing, because there are none — access logging is switched off by configuration, and rate limiting stores only a keyed hash of your IP, deleted when its hour-long window closes, so it lives at most an hour plus the minute until the next sweep. One honest exception: the error log can record an IP when a request fails, which is why the privacy policy names it instead of claiming we keep nothing at all.

We could not read your note if a court ordered us to. The key was never sent to us.

What we could not hand over, even if compelled

Plenty of services promise they would refuse. That is a policy, and policies change with owners, jurisdictions and pressure. The list below is not a promise — it is an inventory of things that do not exist on our side, and a thing that does not exist cannot be produced by anyone, under any order.

  • No decryption key Generated in your browser, carried in the part of the link after the #, which browsers never transmit. We have never held one.
  • No plaintext Encryption happens before anything is uploaded. What we store is unreadable to us at every moment it exists.
  • No filenames The original name and file type are encrypted separately from the bytes. We store a random label.
  • No access log The web server is configured not to write one. There is no record of who opened which link, or when.
  • No account No registration, no email address, no password, no profile. There is nobody to look up.
  • No cookie, no tracker Nothing is set in your browser and no third-party script runs. There is no session to correlate.
  • No stored IP Abuse limits use a keyed hash of the address, deleted when its hour-long window closes, so it lives at most an hour plus the minute until the next sweep. The address itself is never written down.

Two things do exist, and we would rather name them than let you discover them. The error log can record an IP address when a request fails. And the stored ciphertext carries its own metadata — size, creation time, expiry, how many views remain. Both are listed in full, with what an order could actually obtain, on the security page.

Notes, files, or a whole conversation

Notes

A burn after reading note online: text that self-destructs the moment it is read.

Files

Up to 25 MB, encrypted in your browser — the filename and type included.

Chat

A room that exists only while someone has it open. Close the tab and it is gone.

Switching from another service, or still choosing one? Start with how to choose between these tools, or go straight to the comparisons with Privnote and OneTimeSecret.

We are not asking you to take our word for it

We will not pretend to be gods. If someone took control of this server, they could change the code your browser runs. No encryption tool that lives in a browser can rule that out — most simply never mention it.

What we can do is make it impossible to hide. The code is small, hand-written and unminified, and we publish its fingerprint. One command tells you whether a single byte has changed:

Check the code we serve you

curl -s https://notekill.com/assets/app.js | sha256sum

Save the result. Run it again next week, from a different network, or have someone else run it. The same fingerprint means nobody has touched the code — and code altered for one person alone is exactly what that comparison exposes.

Every fingerprint is published at /integrity.json, and the full reasoning is on the security page.

Guides

Short, practical write-ups for the things people actually arrive here to do.