A Privnote alternative you can verify
A fair comparison, including the things Privnote does better.
Privnote made the self-destructing note famous. This page compares it with notekill.com point by point, using only claims you can check yourself.
What Privnote does well
Privnote is the best-known name in this category, and it earned that position. It is long established, and its workflow is as simple as the idea itself: write, copy a link, send it, and the note destroys itself when read. Privnote can send you an email notification when your note has been read — a feature we do not offer, because we never ask for an email address. It is also available in many languages, where we offer fewer. If brand recognition, read notifications, or your language matter most to you, Privnote is a reasonable choice, and this page will not pretend otherwise.
Side by side
Every row is checkable against what each site publishes. Where we could not verify something about Privnote, the table says so rather than guessing.
| Criterion | Privnote | notekill.com |
|---|---|---|
| Brand age and recognition | ✔ Long established; the best-known name in the category | ✘ Newer and smaller |
| Email notification when a note is read | ✔ Yes | ✘ No — we hold no email addresses |
| Language versions | ✔ Many | ✘ Fewer |
| Encryption happens in the browser | ✔ Yes — Privnote's privacy policy describes browser-side encryption | ✔ Yes — AES-256-GCM via the browser's native Web Crypto API |
| Decryption key kept out of the operator's hands | ✔ Yes — Privnote states the key is contained only in the link | ✔ Yes — the key lives in the URL fragment, after the # |
| Third party terminating TLS | ✘ Cloudflare — observed in its response headers, checked 30 July 2026 | ✔ None — TLS terminates on the server we run |
| File sharing | ✘ No — notes only | ✔ Yes — up to 25 MB, filename and type encrypted too (/files) |
| Chat | ✘ No | ✔ Yes — ephemeral rooms, deleted minutes after everyone leaves (/chat) |
| Published hashes of the served code | — not verified | ✔ Yes — /integrity.json, so the code can be checked over time |
| Full legal operator identity published | — not verified | ✔ Trader, registered office, trade register and tax ID on /legal |
| Price | ✔ Free | ✔ Free |
"Not verified" means exactly that. Privnote sits behind Cloudflare, which returns 403 to automated requests, so parts of its site could not be read to check — and we will not publish an absence we have not confirmed. Everything in the Privnote column was either taken from its own published privacy policy or observed directly in its HTTP response headers on 30 July 2026. Infrastructure changes; re-check both columns yourself.
Worth stating plainly, because comparison pages usually avoid it: on the central question — whether the operator can read your note — Privnote makes the same architectural choice we do. Its privacy policy describes encryption in the browser and says the key is contained only in the link. That is the right design, and it is theirs as much as ours. The rows that differ are about what sits in the network path, what else the tool can carry, and how much of the operation is published so it can be checked.
Where the key lives changes everything
Both services delete a note after it is read. The deeper question is whether the operator could have read it first. Our answer is structural: we cannot, because we never receive the key.
When you write a note here, your browser generates a 256-bit key with crypto.getRandomValues and encrypts the text with AES-256-GCM through the browser's native Web Crypto API, with a fresh random 96-bit IV for every encryption. Only the ciphertext is uploaded. The key goes into the part of the link after the #:
https://notekill.com/n/<32 hex characters>#<43 key characters>
BEFORE THE # The note's identifier: 128 bits from a cryptographic random source. Everything before the # is what the server receives, and the identifier is the only meaningful part of it.
AFTER THE # The 256-bit key, encoded as 43 URL-safe base64 characters. Browsers never transmit fragments in HTTP requests, so the key cannot appear in our server logs, in proxy logs, or in a Referer header.
Destruction is enforced on the server, inside a database transaction. In our test, 8 simultaneous readers of a one-view note produced exactly one success and seven 404 responses. The full design, including its limits, is documented at /security.
Check the domain you are on
A well-known brand attracts imitators, and that is not the brand's fault. Security journalist Brian Krebs has documented phishing sites that clone Privnote's name and appearance to intercept what people paste into them. The lesson applies to every secret-sharing tool, this one included: before you type anything sensitive, read the address bar.
Our only address is notekill.com. Bookmark it rather than searching for it. A genuine share link from this service always begins with https://notekill.com/ and always contains a #.
What we admit that most tools don't
The encryption code you run is delivered by our server, so whoever controls that server could in principle serve altered, key-stealing code to future visitors — and Subresource Integrity does not protect you from us, because the same server publishes the hashes. Two things limit the damage: it is forward-looking only, so anything already encrypted stays sealed; and it is detectable, because the hashes at /integrity.json can be archived and compared over time. This is written up plainly at /security#honest-limit, because a comparison page that hides its own weak point would not deserve your trust.
Try it
Write a note at notekill.com — no account, no cookies, nothing to pay — and it destroys itself the first time it is read.
Comparing something else?
Onetime Secret is the other tool people weigh this against, and it is a genuinely different proposition: it is open source and can be self-hosted, which is an advantage we do not have. That comparison, written to the same standard as this one, is at /onetimesecret-alternative.
If you are still deciding which kind of tool you need at all, /alternatives sets out the four questions that actually separate these services — and says plainly when the right answer is to self-host something else instead. The reasoning behind every claim is on /security, and the common questions are answered on /faq.