Honest comparison

OneTimeSecret alternative: Erseni Vault, compared honestly

Both services send secrets that destroy themselves after the first retrieval. The difference lies in who holds the key, and in whether you can also ask someone for a credential instead of only sending one. Both sides are here, including the points where OneTimeSecret is ahead.

GDPR-compliant Hosted in the EU Zero knowledge

Get started free

Create a request link

The short answer

What actually differs

In short: OneTimeSecret has been around far longer, it is better known, and for simply sending a one-time link it is entirely sufficient. Erseni Vault differs on two points that may count for you: the server never sees the plaintext, because encryption and decryption happen in the browser, and you can request credentials from one specific person instead of only sending them.

Point by point

Every line states what each tool does, not just a tick or a cross. Where we are behind, it says so.

Criterion

OneTimeSecret

Erseni Vault

Encryption in the browser (zero knowledge)

OneTimeSecret Encrypted server-side The content is stored encrypted on the server, but the operator holds the key and could technically read it. An optional passphrase adds a further bolt in front of that, though it is not the default path.

Erseni Vault In the browser, the key stays with the link Encryption and decryption happen exclusively in the browser (AES-GCM-256). The key sits in the URL fragment after the #, and browsers never send that part to a server. Erseni therefore only ever holds ciphertext. A note you add to a secret in the dashboard is stored in plain text instead; it labels the secret, it does not contain it.

Requesting credentials from a person

OneTimeSecret Incoming Secrets since July 2026 Version 0.26.0 of 19 July 2026 shipped Incoming Secrets: a drop-off page on a domain of your own, verified by DNS. That is a letterbox whose address you hand out, not a request aimed at one specific person, and its contents are likewise encrypted server-side.

Erseni Vault A request link for one named person You create a request link and send it to exactly one recipient. Their browser generates a key pair locally (X25519), so the answer is end-to-end encrypted, and your dashboard shows you whether it has arrived.

Secrets for AI agents

OneTimeSecret An API for sending OneTimeSecret has a REST API through which a program can create and retrieve secrets. Its documentation describes no way for a program to request a value from a person and hand it only to a command shown beforehand.

Erseni Vault vault-ask and an MCP server An agent requests the value through a link, you enter it in your browser and see the command that will receive it. vault-ask passes it to exactly that command and masks it in its output; it never appears in the chat or the session log.

Account required

OneTimeSecret No for sending, yes for Incoming Secrets Sending a secret works without an account. Using Incoming Secrets requires an account, a domain of your own and its DNS verification.

Erseni Vault Neither for sending nor for requesting Sending and requesting both work without signing up. A free account only adds the dashboard showing the status of your secrets.

One-time retrieval and self-destruction

OneTimeSecret Yes The core of both services: the link works exactly once.

Erseni Vault Yes The first retrieval deletes the record in the same database operation that reads it. A second attempt finds nothing left.

Open source and self-hostable

OneTimeSecret Yes The source code is published on GitHub and can be run by yourself.

Erseni Vault Yes The cryptography component is published under the AGPL in a public mirror and can be self-hosted.

Maturity and adoption

OneTimeSecret Since 2012, widely known The service has run for years, it is established in many teams and its user base is large. That is a genuine advantage.

Erseni Vault Launched 2026, small project Erseni Vault is young, the user base is small and an external cryptography audit is still outstanding. If you need maximum operational maturity, factor that in.

Hosting location

OneTimeSecret Check the operator's own statements This hosting is not in our hands. If the location counts for you, check what OneTimeSecret states itself rather than relying on a third-party comparison page.

Erseni Vault Germany (Hetzner, Falkenstein) Servers and backups stay inside the European Union. The processors are listed individually at /subprocessors.

Where OneTimeSecret is the better choice

Be honest about the fit

Your team already knows and uses the service. Switching costs adjustment, and for simply sending a one-time link it gains you little.

You want a permanent drop-off page under your own domain where people can keep leaving things for you. Incoming Secrets are built for exactly that.

Server-side encryption is enough for you, and you would rather have a service with many years of operation behind it.

The difference that counts day to day: requesting instead of pleading

Requesting instead of sending

The usual sequence takes the problem the wrong way round. You need a password that somebody else holds, so you ask for it by email, and the answer comes back in plaintext by email. One-time-link services do not solve that case: they help whoever is sending something, not whoever needs something. With Erseni Vault you create a request link and send it to the person. Their browser generates a key pair locally, encrypts what they type against it and sends us nothing but ciphertext. You alone can decrypt it. They need no account, no software and no understanding beyond filling in a field.

Create a request link

How it works

Where these statements come from

Sources and limits of this comparison

We compare against public documentation and source code, and we say when we have not verified something ourselves. Products change: if a detail here matters to your decision, check it at the source before you rely on it.

OneTimeSecret on GitHub Release 0.26.0 of 19 July 2026 shipped Incoming Secrets. For the server-side encryption we follow the description given by the project; we have not measured it in the source code ourselves.

Incoming Secrets documentation Describes the drop-off page on a verified custom domain. The page still carries a notice that it is a work in progress.

Erseni Vault source code The cryptography component behind both sending and requesting, readable under the AGPL.