What our server can see
2026-09-25
This post contains affiliate links. As an Amazon Associate, ZAGO.TO earns from qualifying purchases.
Every service in this category says something reassuring about privacy. Most of the reassurance is vague on purpose, because vague sounds better than specific.
Here is the specific version for ours, including the part that does not sound good.
Our server can read your text
When you paste text, it goes to our server as text. It sits there as text. When someone types the code, it is sent back as text.
There is no browser-side scrambling. We have not built it. That means that during the minute or two your text exists on our side, a person with access to that server could read it.
Plenty of services in this space borrow the vocabulary of products where the maths genuinely makes the text unreadable to the operator. We have not done that work, so we do not get to use that language.
What is protected, and what that actually means
The connection between your browser and our server uses HTTPS, which is standard and which every site you use has. That protects the text in transit: somebody watching the café Wi-Fi sees that you contacted us, not what you sent.
That is worth having and it is not the same as us being unable to read it. Transport protection and content protection are different things, and a lot of marketing in this category deliberately blurs them. HTTPS means the postman cannot read the letter. It says nothing about the sorting office.
We are the sorting office.
What we store, and for how long
The text lives in a per-code record that deletes itself. Unopened, that is about a minute. Once opened, about another minute. After that the record is gone and the code goes back into circulation only after a further five minutes, so a code you just used will not immediately hand someone else's message to whoever types it next.
Alongside that, ordinary things exist that any web service has. Our infrastructure provider handles the connection and sees the network-level metadata that comes with any request, including your address. We count requests per address in order to rate-limit: thirty sends and ten failed code or PIN attempts per ten minutes. That counting is by address, and it is how we stop someone typing random four-digit codes all day.
We do not ask for an email, a name, or a password, because there is no account. So there is no user record to associate any of this with, and nothing to leak in the shape of a customer list. That is a genuine consequence of the no-account design rather than a policy we could quietly change.
What we do not have
We cannot show you what you sent yesterday, because we do not have it and never did after the minute ran out.
We cannot tell you whether a specific message was opened, after the fact.
We cannot recover something you sent to the wrong person, or un-send it.
If somebody asked us for a history of what a particular person sent, we would have nothing to hand over, because the thing they are asking about ceased to exist minutes after it happened. That is not a promise about our willingness. It is a consequence of the design, which is the only kind of promise worth much.
What this means for what you send
Work from the assumption that our server can read it, because it can. Then the guidance is straightforward.
Fine: a wallet receiving address, a long URL, a paragraph you wrote, a document to print, a booking reference, a licence key, a Wi-Fi password for a café, setup instructions.
Think about it: anything you would be unhappy to have read by a stranger for one minute. Backup codes sit here. Many people decide that a minute of exposure on our side beats a permanent screenshot in their photo library, and that is a reasonable judgement, but it is a judgement and not a free lunch.
Never: seed phrases, recovery phrases, private keys, anything where a single reading by anyone at all is a total loss. Those do not go into any browser, ours included.
What we would have to build
We know what the missing piece is. Text would be scrambled in your browser before it is sent, with the key travelling as part of what the receiver types rather than being sent to us. Then our server would hold something it genuinely could not read.
That is a real design and it is not exotic. It also changes the product in ways that need thinking through: the key has to ride along with the code, which makes the code longer, and a longer code is harder to say out loud, which is the one thing this service is for. There is a version of that trade we would be happy with and we have not built it yet.
Until we do, we would rather be the service that says plainly what it can see than the one that borrows the vocabulary of services that have done the work.
The honest summary
No account, no history, no customer list. Text deleted about a minute after it is read, and about a minute after it is sent if nobody reads it. Rate limits that are counted by address.
And a server that can read your text for as long as it is there.
Those two paragraphs are the whole picture. If the second one rules us out for something you were considering, that is the correct conclusion and we would rather you reach it here than assume otherwise.