Trust & threat model
No — your secret is scrambled inside your browser before it ever leaves it, and all we ever hold is a locked box we have no key to. Below is exactly how that works, how you can check it yourself, and the one place you shouldn't simply take our word for it.
Only ciphertext. Your browser mints a one-time key, encrypts the secret with it, and tucks
that key into the part of the link after the #. Browsers never send that part to any
server, so the key — and the plaintext — never reach us. The encrypted payload we store is not
something we hold a key to.
Opening is a deliberate click, so link previews, scanners, and chat unfurlers can't spring it by accident. On the final allowed open, the encrypted payload and every scrap of access material are deleted on the spot. Reload the page and there's nothing left.
Every secret carries a timer. When it runs out, the payload is deleted automatically — even if nothing else on our side ever runs. No opens, no leftovers.
Metadata, never contents. Things like when it was created, when it expires, whether it's been opened, and any label you chose. Signed-in users can see this in a dashboard for their plan's window — Free 30 days, Pro 90, Team 365 — while anonymous secrets keep only the bare minimum for abuse control, and not for long. Your keys, passphrases, salts, and the secret itself are never in there.
One thing worth knowing: labels are the exception. They're the part we do keep and show back to you, so treat a label as a filename rather than a note — "staging database" rather than anything you'd mind us holding for the length of your retention window.
Turn it on and we wrap a second lock around your secret (PBKDF2-SHA-256, 600,000 rounds). Now a recipient needs both the link and the passphrase — send them over different channels and a single intercepted message won't be enough to open anything.
Us — and we'd rather say so than let you find out later. The encryption runs in JavaScript that we serve you. That means the honest claim is "we don't read your secrets," not "we physically cannot": a future version of our code could be written to capture a key before it's used, and you'd have a hard time spotting it from inside a browser tab. This is true of every browser-based encryption tool, including the ones that imply otherwise.
What we do about it: the page is locked to script-src 'self', so nothing
third-party can inject code into it; the crypto is plain WebCrypto with no external
dependencies; and everything below is checkable by you rather than asserted by us. If your threat
model includes us specifically, the command-line client is the stronger path — you
install it once, at a version you pin, instead of re-fetching code from us on every visit.
Open your browser's developer tools, switch to the network tab, and create a secret. Two
things to look for. First, the upload request body contains a ciphertext field of
scrambled bytes and no trace of what you typed — search the request for your own plaintext and
you won't find it. Second, watch every request the page makes and note that the part of the link
after the # never appears in any of them; browsers don't transmit it, which is why
we picked it to carry the key. You can do the same on the open page: the reply contains
ciphertext, and decryption happens after it arrives.
Once someone opens a secret they can copy it, screenshot it, or save it — one-time delivery limits how long a secret is exposed, it can't police what a legitimate recipient does next. We also can't help if a device is compromised.
And note what the link itself is: anyone holding the whole URL can open the secret, because the key is in it. If you send it through Slack or email, that system sees the link too, and can open it before your recipient does. Encrypting in your browser protects your secret from us — it doesn't protect it from the channel you send it over. That's what the passphrase above is for: send it by a different route and one intercepted message isn't enough. Think of OneTTL as safe delivery, not endpoint security.
Sending without an account is paced by a short interval between sends plus a daily cap, both counted per network. Signing in moves that budget onto your account instead, so you're no longer sharing a limit with everyone behind your office's connection. We never store your raw IP address — only a truncated, daily-rotated hash that we can drop entirely.
You won't hear us say "military-grade." We use ordinary, well-reviewed building blocks — AES-GCM-256 and PBKDF2-SHA-256 — through the browser's built-in WebCrypto. Boring on purpose.
For the record, the careful wording of everything above:
OneTTL never stores plaintext secrets, decryption keys, passphrases, URL-fragment secrets, or KDF salts. When a secret is opened, expires, or is revoked, the encrypted payload and all access material are destroyed. OneTTL may retain short-lived operational metadata for abuse prevention, reliability, rate limiting, and aggregate metrics. For signed-in users, OneTTL additionally retains dashboard-visible metadata (creation time, expiry, status, open count, creator-selected labels) for the plan's retention window. Metadata never includes secret contents. Recipients can still copy, screenshot, or save a secret after opening it.