BURNEDSECRET::VAULT v1.0.0
$ NEW $ DASH

// DOCUMENTATION

how burnedsecret works.

Zero-knowledge, burn-after-reading secret sharing. Everything below applies to the web app, the REST API and the SDKs alike.

Getting started

  1. Compose. Open /create/secret and type or paste the secret. The plaintext stays in your browser; nothing is transmitted yet.
  2. Encrypt. When you submit, the browser encrypts the content with AES-256-GCM using Web Crypto. Only the ciphertext is uploaded. The encryption key is placed in the URL fragment — the part after # — which browsers never send to the server.
  3. Share. Send the link to the recipient. When they open it, their browser fetches the ciphertext, decrypts it locally with the key from the fragment, and the secret is deleted on that first read.

Need to ask someone for a secret instead? Use a request: open /create/request, describe what you need, and send the submission link. Keep the private view link you get back: it is the only way to open the answer, and the other person's browser encrypts their answer so that only that link can unlock it.

Sign in only if you want the dashboard, bulk CSV uploads, secret requests or API keys. Creating and reading a single secret needs no account. To automate any of this from a pipeline, see /docs/api.

FAQ

What does burn-after-reading mean?

A secret is stored only until it has been read the allowed number of times. On the last permitted read the server marks it burned and the ciphertext is no longer released to anyone, including you. The web app burns on the first read; the API and bulk upload can allow a few more reads (see max views).

A secret also burns when its time-to-live runs out, whichever comes first. Signed-in owners can burn an unread secret early from the dashboard.

What does zero-knowledge mean here?

Your browser or client library encrypts the secret on your own device before anything leaves you. The encryption key never goes to our server. We store an opaque blob of encrypted bytes; we cannot read it, and neither can anyone who breaches our database or serves us a court order. We have nothing to hand over.

For a one-way secret the key is the random string after the # in the share URL, which browsers never transmit. For a request, your browser (or the SDK or CLI) creates a keypair and a random root secret, and you receive a private view link that carries the root after the #. Only that link, or the creating browser's local copy of it, can open the answer. We can technically delete secrets. We cannot technically read them.

↳ Full details: /security

The secret is unrecoverable. The decryption key exists only in the link, so we cannot send it again, regenerate it, or reset it. Create a new secret and share the new link.

The same applies to a request's private view link: if you no longer have the link or the creating browser's local copy, any answer to that request cannot be decrypted by anyone, including us.

How long do secrets live? (TTL)

Every secret has a time-to-live. The web app uses a fixed default of 7 days (604800 seconds, shown as --ttl 604800s (7d) on the create form). Bulk CSV rows can set ttl_days between 1 and 30, and the REST API accepts a ttl of 300, 3600, 86400 or 604800 seconds on POST /api/v1/secrets (default 86400); any other value is rejected with INVALID_INPUT.

A secret is destroyed when it is read or when its TTL runs out, whichever comes first. Once the TTL has passed the server refuses to release the ciphertext, and the link shows the expired state.

How many times can a secret be viewed?

A secret with a higher limit burns after the last allowed read or when its TTL expires, whichever comes first. The limit cannot be raised after creation.

How does passphrase protection work?

An optional passphrase adds a second factor on top of the link. The passphrase is stretched in the browser with PBKDF2-SHA256 at 600,000 iterations and a 256-bit random salt, and the result wraps the content key. The passphrase itself is never placed in the link and never sent to the server.

The recipient needs both the link and the passphrase. Share them over different channels — for example the link by email and the passphrase by phone.

What are access restrictions?

Under Advanced access controls on the create form you can restrict who may open a secret:

Restrictions are enforced by the server before the ciphertext is released. Blocked attempts are listed in the dashboard for signed-in owners.

What are the file size limits?

A text secret carries at most 10 KiB of message. A file secret carries one file of at most 10 MiB, plus an optional message of up to 10 KiB.

Files are encrypted in your browser in chunks (the BSF2 format), so the whole file never has to sit in memory as plaintext, and every chunk is authenticated so a tampered or truncated upload fails closed. The format is specified at /security#crypto-envelopes.

How do requests work?

A request is a secret in the other direction: you ask someone to send you a password. Creating it gives you two links. Send the submission link to the person answering; it carries only your prompt and public key and cannot read the reply. Keep the private view link yourself. When the other person answers, their browser encrypts the reply with your public key and uploads the ciphertext.

Our servers see your prompt, your public key, your webhook URL and a wrapped copy of the private key that they cannot unwrap, then the encrypted answer — never the answer itself. Open the private view link on any device to decrypt the reply locally; it is read once and then burned. The web app, the SDKs, the CLI and the browser extension all work this way.

Can I open a reply on another device?

Yes. Any device that has the private view link can open the reply, once. The browser that created the request also keeps a local copy, so it can reopen the reply without the link being pasted again. Anyone holding the link can read the reply, so share it only with people you trust and never paste it into logs or tickets.

If you lose both the private view link and the creating browser's local copy, the reply is unrecoverable. There is no account, key-file or key-management fallback, and the server has nothing that can decrypt it.

↳ Full details: /security

How do I get an API key?

Sign in, open /keys in the dashboard and choose + ISSUE KEY. The full key is shown once at creation; store it in your secret manager. Keys are sent as Authorization: Bearer <key> and can be revoked from the same tab at any time.

↳ Full details: /docs/api

What are the rate limits and tiers?

Each API key has a daily request limit set by its tier: Standard — 100/day and Partner — 5000/day. The limit is the only quota enforced, and API keys do not expire. Your current tier and limit are shown next to each key at /keys.

Tiers are assigned by the operator. Contact us to change tier.

↳ Full details: /docs/api

How do webhooks work?

When you create a request or an API secret with a webhook_url, we POST a small JSON event to that URL when the request is fulfilled (request.fulfilled) or the secret is burned (secret.burned). The payload carries the request or secret id and a timestamp — never the answer, a key, or a link with a key fragment.

Every delivery is signed with HMAC-SHA256 over the exact body bytes; verify the X-Signature header with the SDK helper before acting, then look up the private view link you saved when you created the request and read the reply with it. The webhook never contains that link. See /docs/api#webhooks-step.

↳ Full details: /docs/api

Where is the security model documented?

The plain-language model — what we can and cannot see, and how this differs from encryption at rest — is on the security page. The same page carries the crypto envelope specification for SDK authors at /security#crypto-envelopes, and interop test vectors are published at /api/v1/test-vectors.json.

↳ Full details: /security