How OneTimeSecret says it protects a secret
Onetime Secret's security overview describes its model in brief: a secret is designed to be viewed once and then permanently destroyed, an unviewed secret can be burned, secrets are encrypted in transit and at rest across all plans, every secret carries an expiration, and an optional passphrase adds a layer the link alone cannot open. Its data protection page adds that transport is protected with TLS, that it aims to keep only the metadata needed to operate the service, and that you can choose the region where data is processed and stored. The homepage states that once the recipient opens the link the data is permanently destroyed and no one, including Onetime Secret, can retrieve it.
Those are the right properties for a one-time secret tool, and they are stated clearly.
The one thing the documentation does not say
Neither the security overview nor the data protection page says where the encryption happens: in your browser before the secret is sent, or on Onetime Secret's servers after it arrives. The distinction decides whether the operator could read a secret while it is stored. Encryption at rest protects the database from someone who steals the disk; it does not by itself prevent the service that holds the key from decrypting the record. The pages also do not describe how a passphrase is processed or stored, and the expiry maximum is given only as a plan limit.
This is not an accusation. Onetime Secret is open source and self-hostable, so anyone who needs to know can read the code or run their own instance, which is a stronger guarantee than any marketing page. It is simply a question the hosted service's documentation leaves open, and if your threat model includes the operator, it is the question to ask.
One time secret review: what it does well
It is simple, free for individuals and teams, open source, and self-hostable with a linked GitHub repository. Burn before view, passphrases and expiry cover the controls most people need. Choosing a data region is something few competitors, including LinkPilot, offer. For an occasional personal secret, or for a team that wants to run the service itself, it remains a sound choice.
Where LinkPilot differs
LinkPilot answers the open question explicitly: the secret is encrypted in your browser with AES-GCM-256, the key is placed after the # in the link where browsers never send it, and our servers, database and edge hold ciphertext and no key. The code that does this ships in the MIT-licensed CLI repository with test vectors. The security architecture page states the model and its limits, including that secrets created before 29 September 2026 were stored as plaintext until they expired and that an attached file's name, size and type are visible to us.
Around the secret, LinkPilot adds revocation from a dashboard, file attachments, team roles, and on Pro a passphrase mixed into the decryption key and an audit timeline. What it does not offer is self-hosting or a data region choice; the OneTimeSecret alternative page and the full comparison weigh those trade-offs.