How to share a password securely in 30 seconds
You need to send a Netflix password to your sister. Or a Wi-Fi password to a guest. Or an admin login to a family member who got locked out. The usual move is typing it into whatever’s open: WhatsApp, iMessage, email, sometimes a photo of a Post-it.
All of those store the password somewhere you can’t clean up. It ends up in the recipient’s chat history, in their device backup, on the messaging company’s servers, and in your own sent folder. Deleting the message on your end removes one copy, not the others.
A one-time encrypted note handles the rest. The note is encrypted in the browser before it leaves the device, so the server only ever stores ciphertext. Notes are one-time by default: the server deletes its copy the moment the note is opened. If nobody opens it, it expires on its own.
Where the password actually ends up
- iMessage and WhatsApp: both devices. If iCloud Backup or Google Drive backup is enabled, also pushed to the cloud.
- Signal: both devices. Backups are end-to-end encrypted, whether stored locally or via Signal Secure Backups, so the provider cannot read them. The password still sits in both chat histories until somebody deletes it.
- Email: sending server, receiving server, both inboxes, and whatever archive policy the provider has configured.
- SMS: both phones, plus the carrier: not encrypted end to end, so it is readable there and kept for as long as their policy says.
- Photo of a Post-it: two camera rolls and the cloud behind each one.
Deleting the message on your side doesn’t touch the copies the infrastructure already made. A year later, when one of those backups leaks, the password is still in it.
How the alternative works
The browser encrypts the note (or a file) with a password before upload; the server never sees plaintext. After upload you get a short URL and the password itself, displayed separately. You share both.
The recipient opens the URL and types the password. The browser decrypts it locally. A one-time note or file is used up as soon as it is opened: once the first encrypted byte has been sent, the link is spent, even if the transfer breaks. Every upload also has a TTL (an expiry timer, 1 day unless you change it), and when it runs out the upload is deleted whether anyone opened it or not.
30-second workflow
- Open ttl.space.
- Switch to Note and paste the password. Notes are one-time by default; for a file, drop it in and turn on Burn after reading.
- Copy the link and the password from the success page. They are two separate values.
- Send them. For anything sensitive, split across two channels: link over WhatsApp, password over SMS. Compromising one channel alone does not yield both. Handing it over in person? The QR code button lets the other phone scan the link from your screen.
- Keep the page open, or press Notify me, to see the moment the note is opened.
Burn after reading and TTL
Burn after reading fits a handoff happening in the next few minutes: the note is gone the moment it is opened. The expiry timer runs either way, so there is nothing to gain by turning burn off: for “read it when you get home”, the default 1 day is usually enough.
Knowing it has been read
The success page shows when the note is opened (“Opened · 14:02”). With Notify me, your browser tells you even after you close the tab. My uploads lists what you sent from this browser with its status, and lets you delete a link early if it went to the wrong person.
Limits
Once the note is opened, the password is in the recipient’s hands. Screenshots, sticky notes, smart speakers: all outside the protocol. So is whatever is running on their device; a keylogger or a malicious browser extension sees what they see.
The password’s own strength matters more than how it was sent. password123 is guessable in seconds regardless of transport. Generate strong passwords in a password manager, then use a one-time link to move them.
None of this removes past exposure. If the password is already in an old Slack thread or a Google Doc, rotate it first.