The safest way to send someone a password is a one-time secret link: paste the password into an end-to-end encrypted note, share the link, and let it destroy itself once it has been read. DNSX encrypts the note in your browser with AES-256-GCM, so the password is never stored in an inbox, a chat log, or on our servers.
Send a Password Securely
One-Time Secret
Share passwords, API keys, and sensitive data securely. Secrets are encrypted end-to-end in your browser and auto-delete after viewing.
0 / 100,000 characters
Without password, encryption key will be in the URL fragment (never sent to server)
How It Works
True End-to-End Encryption
Your secret is encrypted in your browser using AES-256-GCM before being sent to the server. Without a password, the encryption key is stored only in the URL fragment (the part after #), which is never sent to our servers.
Self-Destructing
Secrets are automatically deleted after being viewed the specified number of times, or when they expire - whichever comes first.
Zero Knowledge
We never see your unencrypted data. With password protection, the key is derived from your password using PBKDF2. Without a password, the key exists only in the URL fragment.
API Usage
The secret API requires client-side encryption. The server stores only pre-encrypted blobs and cannot decrypt your secrets.
For CLI/API usage, you must encrypt your content with AES-256-GCM before sending it to the server. The encryption key should be shared via the URL fragment (after #) or derived from a password using PBKDF2.
For the simplest experience with true end-to-end encryption, use this web interface.
How do I send a password securely?
Send the password as a one-time link rather than as text in a message. The password is encrypted in your browser, the recipient opens the link, and the stored copy is destroyed once the view limit you set is used up. Nothing durable is left behind on either side of the conversation.
- Paste the password or key into the box above, up to 100,000 characters. It is encrypted in your browser with AES-256-GCM before any request is made.
- Set the view limit and expiry. One view and one day are the defaults. The link can allow 1, 2, 5, 10 or 15 views, and expire anywhere from 1 hour to 30 days. Whichever limit is reached first ends the secret.
- Add a password if the link will travel on a risky channel. The encryption key is then derived from that password with PBKDF2-SHA256 at 600,000 iterations instead of being carried inside the link.
- Use two channels. Send the link one way (email, a ticket, a chat message) and the password another, such as a phone call. Neither channel alone is then enough to read the secret.
One last habit. Send the username through your normal channel and only the password through the link. A bare credential with no account name attached to it is far less useful to whoever intercepts the link.
Why is emailing a password unsafe?
Emailing a password is unsafe because email is designed to keep copies. A single message leaves one copy in your Sent folder, one in the recipient's inbox, and more on both mail providers' servers and in their backups. Deleting your copy does not delete anyone else's, and a message that went to the wrong autocompleted address cannot be taken back.
The same reasoning applies to chat and SMS. Slack and Teams retain direct messages under a policy the workspace administrator controls, and administrators can export that history. Text messages sit on two phones and in whatever cloud backup those phones use. In every case the password outlives the moment it was needed, in a place neither party is watching.
Gmail Confidential Mode does not solve this. It is not end-to-end encrypted: Google can read the message, and the expiry is enforced by the Gmail interface rather than by cryptography. The recipient can still screenshot or retype the contents, and the message stays on Google's servers regardless of what the timer displays.
Email, Slack or SMS vs a one-time link: what persists where?
| Channel | Where copies end up | How long it lives | Can you take it back? |
|---|---|---|---|
| Your Sent folder, their inbox, both providers' servers, Trash, mailbox backups, and every forward. | Indefinitely. Deleting your copy leaves theirs untouched. | No. | |
| Slack / Teams | The workspace message store, including direct messages, plus admin exports and eDiscovery archives. | As long as the workspace retention policy says, which is often forever. | No. Deleting the message does not clear the export. |
| SMS / messaging apps | Both handsets, plus whichever cloud backup each phone syncs to. | Until both devices and every backup of them are wiped. | No, and you cannot see the other device. |
| Shared document or wiki | The document body plus its full revision history, which usually keeps the deleted text. | For the life of the document, and often beyond it in version history. | Only by purging revision history, if the tool allows it. |
| DNSX one-time link | Ciphertext on our server; the key is in the URL fragment or in the password you never sent us. | Until the view limit is used or the expiry passes, and never more than 30 days. | It takes itself back. After the last view the link returns nothing. |
Email, Slack and SMS all encrypt in transit. What separates the rows above is how many copies each channel leaves behind once the message has arrived, and how long they stay there.
What is a self-destructing link?
A self-destructing link is a URL that carries a message which is deleted once it has been read, or once a time limit passes. The secret never travels through email or chat itself. Only a pointer to encrypted storage does, and that pointer stops working once the recipient has used it up.
On DNSX both limits are yours to set, and whichever is reached first ends the secret. Once the view limit is used, the secret is marked destroyed in the same database write that serves it, so the link immediately returns nothing. A cleanup job then deletes the stored row. A secret nobody opens is destroyed at its expiry time anyway.
| Setting | Options | Default |
|---|---|---|
| Views before destruction | 1, 2, 5, 10 or 15 | 1 view |
| Expiry | 1 hour, 5 hours, 1 day, 3 days, 7 days, 14 days or 30 days | 1 day |
| Secret size | Up to 100,000 characters | No default |
| Password protection | Optional; key derived with PBKDF2-SHA256 at 600,000 iterations | Off (key travels in the URL fragment) |
| Account | None. No signup, no paid tier, no ads, no tracking cookies | Not applicable |
Can DNSX read my secret?
No. Your secret is encrypted in your browser with AES-256-GCM, using the Web Crypto API, before any request leaves the page. What our server receives and stores is the ciphertext, a random 12-byte initialisation vector, and in password mode a random 16-byte salt. It never receives a key, so it has nothing to decrypt with. That is what zero-knowledge means here: the guarantee comes out of the code, and does not rest on us behaving well.
Default mode: the key lives in the link. When you do not set a password, your browser generates a random key, encodes it in base58 and appends it to the URL after a #. Everything after the # is the URL fragment, and browsers never include the fragment in an HTTP request, so it stays out of our server logs and out of referrer headers. The recipient's browser reads the key from its own address bar and decrypts locally. The trade-off is that anyone who gets hold of the whole link can read the secret before the intended recipient does.
Password mode: the key is derived from something we never see. When you set a password, the key is derived from it using PBKDF2-SHA256 with a random 16-byte salt and 600,000 iterations, matching current OWASP guidance. The password itself is never transmitted. Only the salt and the ciphertext are stored. Once someone has fetched the stored blob they can guess offline at full speed, and no server-side rate limit can help, so those 600,000 iterations are the whole brute-force defence. That is why deriving the key takes a visible moment in your browser, and why a short password is a bad choice here.
AES-256-GCM is authenticated encryption, so tampering is detected rather than silently decrypted: a modified ciphertext fails outright instead of yielding altered text.
Encryption terms used on this page
End-to-end encryption
End-to-end encryption means the data is encrypted on the sender’s device and decrypted only on the recipient’s device, so no server in between ever holds a usable key. DNSX encrypts secrets with AES-256-GCM in the browser using the Web Crypto API.
URL fragment
The URL fragment is the part of a link after the # character. Browsers keep it local and never include it in the HTTP request, so a decryption key placed in the fragment reaches the recipient without ever reaching the server, its logs or its referrer headers.
Zero-knowledge storage
Zero-knowledge storage means the service holds only ciphertext and never the key needed to read it. A DNSX secret row contains an encrypted blob and, in password mode, a random salt. It holds nothing that can be turned back into the plaintext.
AES-256-GCM
AES-256-GCM is an authenticated encryption mode: it provides confidentiality with a 256-bit key and also detects tampering, so a modified ciphertext fails to decrypt instead of returning altered text. Each DNSX secret uses a fresh 12-byte random initialisation vector.
PBKDF2-SHA256
PBKDF2-SHA256 turns a human password into an encryption key by hashing it repeatedly with a random salt. DNSX uses 600,000 iterations, the current OWASP guidance for PBKDF2-SHA256, which makes each offline guess of the password expensive.
Self-destructing link
A self-destructing link is a URL whose contents are deleted after a set number of views or after an expiry time, whichever comes first, so the secret cannot be read again from the same address.