scrt.link vs OneTimeSecret
Both create self-destructing links. Only one encrypts the secret in your browser before it reaches the server.
OneTimeSecret has been running since 2011 and is the tool most people find first. It is open source, well maintained, and deliberately minimal — it shares short text secrets, once.
The difference that matters is where encryption happens. OneTimeSecret states that "decryption keys live on the application server". Your secret arrives at their server as plaintext and is encrypted there. scrt.link encrypts in your browser first: the key lives in the part of the URL after the #, which browsers never send to a server. We cannot read your secret, even if we wanted to.
OneTimeSecret also shares text only — no files — and every link is strictly one view.
Feature comparison
| Feature | scrt.link | OneTimeSecret |
|---|---|---|
End-to-end encrypted in the browser | ||
Decryption key never reaches the server | Only with a passphrase | |
Open source | Yes (MIT) | Yes (MIT) |
Self-hostable | ||
File sharing | Up to 100 GB | Not supported |
Text secret size | Up to 100,000 characters | 100 KB anonymous, 1 MB with account |
One-time (burn after reading) links | ||
Configurable view limit | Up to 1,000 views | One view only |
Expiration | 10 minutes – 30 days | Up to 7 days anonymous, 30 days on paid plans |
Password protection | Yes (paid plans) | |
One-time redirects & file requests | ||
REST API | ||
Official CLI | Yes (@scrt-link/cli) | None official |
Browser extension | Chrome & Firefox | None official |
Custom domain / white-label | Yes (Business) | |
Works without an account | ||
Ad-free |
Facts about OneTimeSecret last verified on July 14, 2026. Products change — if something here is out of date, let us know and we'll fix it.
Key differences
Where the encryption happens
OneTimeSecret encrypts your secret on their server, using a key their application holds. That is meaningfully safer than storing plaintext, but it means the service is in a position to read your secret, and a compromise of the server is a compromise of the secrets in flight. scrt.link encrypts in the browser and puts the key in the URL fragment — the part after # that browsers never transmit. Their own security guidance even suggests encrypting content yourself before pasting it in, for highly sensitive data.
Passphrases change the picture — partly
OneTimeSecret's optional passphrase is folded into the encryption key and only a hash is stored, so with a passphrase set they can no longer decrypt the secret after it is saved. It still travels to their server as plaintext at creation time, and it only helps if you remember to use it and can get the passphrase to the recipient over a second channel.
Text only, versus text and files
OneTimeSecret shares text and nothing else — that is an explicit design decision, and their FAQ points you to a separate file transfer service if you need one. scrt.link handles both from the same place: text secrets, files up to 100 GB, one-time redirects, and secret requests where someone sends you something securely.
One view, versus up to a thousand
Every OneTimeSecret link is strictly single-view. That is the right default, but it breaks down when a link needs to reach a team, or when a recipient accidentally opens it on the wrong device. scrt.link lets you set a view limit anywhere from 1 to 1,000 on paid plans, so you can pick the trade-off yourself.
Which one should you use?
Choose scrt.link if…
-
You want the service provider to be structurally unable to read your secrets, not just promising not to.
-
You need to send files, not only text.
-
You want a link that can be opened more than once, or a longer expiration window.
-
You want an official CLI, browser extensions, and a REST API in the same product.
Choose OneTimeSecret if…
-
You want the most established option — it has been running since 2011 and is trusted by a lot of people.
-
You only ever share short text and value an interface with nothing else in it.
-
You want a custom domain without paying: their free Basic tier includes one.
-
You want to self-host something with a small, well-understood footprint (Ruby + Redis).
Frequently asked questions
Got a Question?
Whether you need help choosing a plan, have a technical question, or want to discuss a custom setup — we’re here to help. No bots, no ticket queues. You’ll hear back from a real person.