Choosing a self-destructing note service
Four questions that separate these tools, and an honest account of when the answer is not us.
There are a dozen tools that will send a secret once and then destroy it. They are not interchangeable, and the differences that matter are rarely the ones on the front page. This is a guide to choosing between them — including the cases where the answer is not us.
Start here: can you self-host?
If your organisation can run and maintain its own instance, do that, and stop reading comparison pages. Self-hosting an open-source tool removes the outside operator from the question entirely. You are then trusting code you chose and a machine you control, instead of trusting a company you found through a search engine. That is a materially better position, and no hosted service — ours included — can match it.
Every hosted tool in this category, ours included, shares one residual risk: the encryption code is delivered by the server each time you load the page, so whoever controls that server could in principle serve altered code to future visitors. Published hashes and a strict Content-Security-Policy make that detectable rather than impossible. We write this up in full on /security, and we would rather you weigh it than discover it.
The rest of this page is for the other situation, which is far more common: you need to send one password, one file or one message right now, to one person, and standing up infrastructure is not on the table.
The four questions that actually separate these tools
- Where does the encryption happen? In your browser, or on their server after you send them the plaintext? If it is the second, the operator can read your secret, whatever the marketing says. Everything else is secondary to this.
- Where does the decryption key live? The strong design puts it in the URL fragment — the part after the # — because browsers never transmit that in an HTTP request. If the key is in the path or a query parameter, it reaches the server and gets written to logs.
- Who else sits in the network path? A CDN or reverse proxy in front of the site terminates TLS, which means it handles the decrypted HTTP request. That is a second organisation with a technical position, whatever its policies say.
- What can you check without taking their word for it? Published code hashes, an open repository, a named legal operator. Anything that turns a claim into something testable.
Our comparisons
Each page below follows the same rule: only publicly documented facts, competitors' genuine strengths stated plainly, our own limitations stated just as plainly, and "not verified" written wherever we could not confirm something rather than a guess dressed as a finding.
- Yopass — the closest technical peer here. Browser-side encryption you can confirm in its source, key in the fragment, Apache-2.0, self-hostable. If you can run it yourself, do.
- Password Pusher — encrypts server-side and says so in its own documentation, which is rarer and more honest than it sounds. Richer expiry controls than ours, and an audit trail we do not offer.
- Onetime Secret — open source and self-hostable, which is an advantage we do not have. Read this one early if self-hosting is even slightly possible for you.
- Privnote — the best-known name in the category, and it earned that. Where it matches us architecturally, and where the paths differ.
Where we think we are the right answer
When you need more than a note. Most tools in this category carry text and nothing else. This one also carries files up to 25 MB with the filename and type encrypted alongside the contents, and ephemeral chat rooms that erase themselves minutes after the last person leaves. All three use the same design: encrypted in your browser, key in the fragment, nothing readable ever stored.
When you want the operation checkable. The hashes of every file we serve are published at /integrity.json, and /verify runs the comparison in your own browser against what your browser saw last time. The company behind the service is named in full on /legal — trade register, tax identifier, registered office. Not because anyone required it, but because an operator you cannot name is an operator you cannot hold to anything.
Where we are not
If you need it self-hosted, use an open-source tool and run it yourself. That is the stronger answer and we will not argue otherwise.
If you need files larger than 25 MB, this is the wrong tool. The limit is real and we would rather say so than have you discover it mid-upload.
If you need an email notification when your note is read, we cannot do it, because we never ask for an email address. Some competitors can. That is a genuine trade-off, not a flaw in either direction.
If you are sharing a cryptocurrency seed phrase, do not use this or anything like it. A seed phrase should never touch an internet-connected transmission channel, encrypted or not. Write it on paper.
Try it
Write a note at notekill.com, share a file on /files, or open a room on /chat. No account, no cookies, nothing to pay. The full design is on /security, and the questions people actually ask are answered on /faq.