A password you send in a messenger doesn't go anywhere: it sits in the history, in the backup, in the recipient's cloud, and three years from now anyone who gets into any of those places will find it.
Same with a file: email it, and it sits on the mail server in the clear no matter how many times you delete the message on your end. Here are four ways to hand over a secret so that afterwards it exists nowhere except with the person you sent it to. All of them work in the browser, nothing to install.
WHERE A SECRET SETTLES
messenger history, backup, cloud
email sender's server and
recipient's server
cloud with the service, forever
└─ deleting on your end isn't
deleting everywhereWay 1: a note that burns
For a password, a code, a card number, anything short. Type the text into a burning note: it gets encrypted right in the browser, you get a link, and after the first read the note is gone. If nobody opens it within the time you set, it burns on its own.
The key part of this design: the key lives in the link itself, after the # sign. That's the URL fragment (the part of the address after the hash mark, which the browser never sends to the server), and that's how the protocol itself works. What reaches the server is the encrypted string and its name, which is also derived from the key. We've got nothing to decrypt it with. That's not a promise, it's the absence of a key.
Worth understanding up front: if the wrong person opens the link, they read the note, and the real recipient sees it's already burned. There's an upside to that: you find out right away that the link went astray. But the note protects against a secret living forever in a chat, not against someone grabbing the link. And a messenger's link preview doesn't burn the note: reading happens by a button on the page, not by visiting it.
Way 2: a file straight across, skipping the servers
For a file of any size that shouldn't sit anywhere. 404 Send moves it from your browser to the recipient's browser directly. The file never lands on our servers: we only relay an encrypted envelope describing the connection so the two browsers can find each other. We don't see the file, its name, or either side's address.
Two limits, both honest. First: until the recipient opens the link and taps Accept, the file sits on your disk and the transfer hasn't started. So you can't close the tab; this isn't an upload to a server, it's a direct connection, and one side doesn't work without the other. The link lives ten minutes. Second: size is limited by the recipient's memory, since the browser assembles the whole file before saving it.
Who it's for: two people who are both at their screens right now. Who it's not for: a recipient who'll open it "at some point." That's way 3.
Way 3: lock it with a password and send it however
For a file that's going by email or cloud because anything else is a hassle. Encrypt the file with a password before sending: the password becomes a key, the file becomes a blob of bytes nobody can read without it. It uses AES-256 (the standard cipher, the same one banks and messengers use) in a mode that doesn't just hide the contents but also notices if the file got swapped or corrupted along the way. Everything is computed in the browser, the file isn't uploaded anywhere.
For a short text the same thing is done by text encryption: you get one string you can paste anywhere.
Why it beats a password-protected archive: nothing to install, and the algorithm is modern for sure. Encryption on old ZIP archives breaks in minutes, and you can't tell from the file which kind is inside a given archive.
One rule that makes this way work: send the password through a different channel than the file. File by email, password by voice or in a messenger, or the other way around. The point is separation: if the conversation gets read, it shouldn't contain both the file and the key to it. And second: a forgotten password is a lost file. We store no passwords, no keys, no copies. There's nothing to recover and nobody to recover it.
WHAT GOES WHERE
password, code, number burning note
file, both at screens direct, Send
file, recipient opens password-lock it,
it later send it however
ongoing exchange encrypt to a key
└─ the file's password always
goes by another channelWay 4: encrypt to the recipient, no shared password
If you swap secrets with someone all the time, inventing and passing along a password every time gets old. Then it's encrypt to a recipient: they publish their public key once, you encrypt to it, and only they can decrypt with their private key. No shared password, nothing to hand over, nothing to intercept. It's the same scheme all end-to-end messaging runs on, just without the app.
What I'd actually do
Straight up. Wi-Fi password for a guest: a note for an hour. A contract for the accountant: password-lock it, file by email, password by phone. A hundred photos for a friend: Send, while we're both at our screens. Regular exchange with the same person: swap keys once and forget about passwords.
What I wouldn't do: send the password in the same chat where the link to the note is. The note protects against storage, not against whoever's reading that chat right now.
BEFORE SENDING
[ ] the secret won't stay in the chat
[ ] file password goes by another channel
[ ] note link isn't next to a password
[ ] recipient knows it opens once
└─ four items, one minuteWhat these ways don't do
They don't protect against someone who's already reading your chat or email in real time: they grab the link and open the note first. Only a different channel saves you from that. They don't verify the recipient is who they claim to be: if you send a password to a scammer, the encrypted password reaches the scammer in perfect shape. And they've got nothing to do with a VPN: a tunnel hides your address from the network, but a secret doesn't leak from the network, it leaks from the chat history. What a tunnel hides and what it doesn't is in what is a VPN and how does it work.
One more thing from the same family: the password you're handing over might already be in a breach database. You can check that in a second without sending it anywhere, and how that works is in how to check if your password was leaked.
If you can't tell which way fits your case, describe it to an AI.
Help me pick how to send a secret.
What I'm sending: (password / code / file, what
size / many files).
To whom: (once / the same person regularly).
Recipient is at their screen now: (yes / no).
Channel we already use: (messenger / email /
phone).
Tell me which way fits, and which second channel
to use for the password if one is needed.In short
A secret in a messenger or email stays there forever. Something short: a note that burns after reading, key in the link, we don't have it. A file right now: straight between browsers, skipping the servers. A file for later: password-lock it and send it however, with the password by another channel. Ongoing exchange: encrypt to the recipient, no password at all.