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 short-lived encrypted link handles the rest. The file is encrypted in the browser before it leaves the device, so the server only ever stores ciphertext. When someone downloads it, the server deletes its copy. If nobody downloads 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, 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: carrier storage for years, plus both phones.
- 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 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 the file locally. If you turned on burn-after-read, the server deletes its copy once that download completes. If you set a TTL instead, it deletes on the clock, whether anyone downloaded it or not.
30-second workflow
- Open ttl.space.
- Put the password into a small text file or a note and drop it into the upload area.
- Turn on burn-after-read.
- 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.
Burn-after-read vs. TTL
Burn-after-read fits a handoff happening in the next few minutes. TTL fits one that will happen later in the day; 24 hours is usually enough for “read it when you get home.”
Limits
Once the file is decrypted, the password is under the recipient’s control. Screenshots, sticky notes, smart speakers — 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.