An Onetime Secret alternative where the server never holds keys

One architectural difference, explained fairly — and an honest recommendation about when you should use theirs instead.

Onetime Secret is one of the most established tools for sending a secret that destroys itself after it is read. This page sets out where it is stronger than this service, where the architecture differs, and which one fits which situation.

Onetime Secret is good software

We want to say that without qualification. Onetime Secret is open source: anyone can read the code, audit it, and run their own instance. It has a documented API, so it can be scripted into other systems. It has a long operating history, a company behind it, and paid support for organisations that need a contract and a person to answer. It has earned its reputation.

This service has none of those things. Our frontend is hand-written vanilla JavaScript with no framework, no build step and no minification, so the code you audit is the code that runs — but it is not open source, there is no API, and there is nothing to self-host. We are the smaller, narrower tool.

One architectural difference

Onetime Secret's own documentation states that decryption keys are held on its application server. That is a deliberate design, and it buys real capability: when the server holds the key, it can offer features such as passphrase changes, and burn logic can operate server-side on the secret itself. The trade-off is equally plain. A server that holds the key is a server that is able to read the secret. You are trusting the operator's conduct as well as the cryptography.

We made the opposite choice. When you create a note here, your browser generates a 256-bit key with crypto.getRandomValues and encrypts the content locally with AES-256-GCM through the browser's native Web Crypto API. The key is placed after the # in the share link, and browsers never transmit that fragment in HTTP requests, so the key cannot reach our server, our logs, or a proxy on the way. Burn-after-read is still enforced on our server, inside a database transaction: in our test, eight simultaneous readers of a one-view note produced exactly one success and seven 404s. But the server only ever deletes ciphertext it cannot open.

The cost is symmetrical. We cannot recover a lost link, and we cannot offer any feature that requires our server to see content — passphrase changes included. Lose the link and the data is gone. What the choice buys is narrower and, in some situations, decisive: we are structurally unable to read what you share, so on that specific point you are not relying on our restraint — subject to one limit that applies to any tool whose encryption code is delivered over the web, covered below and on /security.

Side by side

Comparison of Onetime Secret and this service across openness, support, and architecture
Aspect	Onetime Secret	This service
Open source	Yes	No
Self-hosting	Yes — run your own instance	No
Documented API	Yes	No
Company with paid support	Yes	No — free, no paid tier
Operating history	Long	Short
Where the decryption key lives	On the application server, per their documentation	In the URL fragment; it never reaches the server
File sharing with encrypted filenames	—	Yes — up to 25 MB, filename and type encrypted in the browser
Ephemeral chat	—	Yes — rooms deleted minutes after everyone leaves; inactivity
CDN in the TLS path	—	None; TLS terminates on our own server
Web-server access logging	—	Disabled for this site
Published integrity manifest	—	Yes — integrity.json

A dash means we make no claim about Onetime Secret on that row; check their documentation. And one caveat on our side: access logging is off, but our web server's error log still exists and can record an IP when a request fails — see /privacy.

If you can self-host, self-host

Any service that delivers its encryption code from the web carries this residual risk, and we are no exception. The encryption code is delivered by the server, so whoever controls the server could in principle serve altered, key-stealing code to future visitors. Subresource Integrity and a strict Content-Security-Policy do not remove this, because the same server publishes the hashes. Two things limit it: already-encrypted data stays sealed, and the change is detectable, because our hashes are published at integrity.json and can be archived and compared. The trust does not reach zero.

Self-hosting Onetime Secret removes the outside operator from that equation. The code runs on your own infrastructure, under your control, and nobody else sits in the path — you are then trusting the code you chose to deploy and the machine you run it on, which is a materially better position to be in. If your organisation can stand up and maintain an instance, that is the stronger answer, and we recommend it plainly.

This service exists for the other case: you need to send one password or one file now, once, to one person, and you have no server and no time to build anything. Open the page, encrypt in your browser, send the link. No account, no cookies, no cost.

Comparing something else?

Privnote is the other name that comes up in this search, and it works quite differently from Onetime Secret — different terminology, different audience, different trade-offs. The side-by-side is at /privnote-alternative, written to the same rule as this page: only publicly documented facts, and our own limitations stated as plainly as theirs.

For the wider question of how to pick between any of these tools, /alternatives lays out what actually differs between them and where we are the wrong choice. And if you would rather check claims than read them, /verify runs the integrity check in your own browser.

Try it

Create a note, share a file on /files, or open a room on /chat — everything is encrypted before it leaves your browser, and the full design is described on /security.