You just reset a shared account's password, or you're handing a Wi-Fi key to a houseguest, or a client needs a login for a portal. The easy move is to paste it straight into Slack, WhatsApp, or an email. The problem: that message doesn't disappear. It sits in your chat history, the recipient's chat history, both parties' cloud backups, and any device either of you is signed into, indefinitely — in plain text, readable by anyone who later gets into any one of those places.
Here's how to send a password securely instead: encrypt it before it touches a chat or email thread, and split it from its own decryption channel.
Why pasting it in chat is the weak point
A password typed into a messaging app isn't "sent and gone." It's stored, usually more than once:
- Chat history, searchable by anyone who later gains access to either account.
- Cloud backups of that chat, often kept far longer than the conversation itself.
- Notification previews, which can flash the password on a lock screen.
- Server-side logs, if the tool routes messages through a provider you don't control.
None of that requires anyone to "hack" anything — it just requires someone who already has access to one of those places, at any point in the future. The fix isn't a better messaging app. It's not leaving a readable secret in any of those places to begin with.
Encrypt the secret, then send the encrypted version
FileX's Secret Note tool turns your message into ciphertext before it ever leaves your device:
- Open the Secret Note tool and type or paste the password (or address, or message) into it.
- Set a password to protect it. This encrypts the text locally with AES-256-GCM, the same authenticated cipher FileX uses for file encryption — the key is derived from your password with PBKDF2-HMAC-SHA256 and a random salt, run entirely in your browser.
- Copy the output. It's a plain-text block —
----- BEGIN FILEX NOTE -----…----- END FILEX NOTE -----— that pastes cleanly into any chat app, email, or ticket, because it is just text, base64-encoded. - Send that block over whatever channel you'd already planned to use.
Nothing about this step touches a server. The note is encrypted on your device and never uploaded — you can check the "nothing uploaded" monitor on the page while you do it.
To read it back, the recipient pastes the block into the same tool's Decrypt mode and enters the password. If the password is wrong, or the block was altered in transit, decryption fails outright rather than returning garbled text — that's the authentication tag in AES-GCM doing its job, the same mechanism covered in how AES-256-GCM keeps your files safe.
The part that actually matters: use a second channel
Encrypting the note only helps if the password protecting it doesn't travel the same path as the note itself. If you encrypt a secret and then send both the encrypted block and its password down the same Slack thread, you've just moved the plaintext-in-chat problem one message later — anyone who can read that thread can decrypt the note too.
Split it instead:
- Send the encrypted note by chat, email, or a shared doc.
- Deliver the password by a different channel — a phone call, an SMS, in person, or a separate app entirely.
An attacker (or a future account compromise) now has to control two channels, not one, to reconstruct the secret. That's the entire value of encrypting it in the first place — don't undo it by keeping the password on the same thread.
Don't reuse a weak password for the wrapper either
The password protecting your note is doing real cryptographic work — it's the input to the key derivation, and a short or guessable one narrows the search space an attacker has to try. Don't reuse an existing account password as the wrapper; generate a fresh one for this purpose with FileX's password generator, which draws randomness from your browser's CSPRNG (crypto.getRandomValues, never Math.random) rather than anything predictable:
- A random password (8–64 characters, with toggles for lowercase, uppercase, digits, and symbols) — every character sampled with unbiased rejection sampling, one character guaranteed from each class you select.
- A diceware-style passphrase (3–10 words from a 7,776-word list, optionally capitalized or suffixed with a number) — easier to read aloud over that phone call than a random string, and just as calculable: each word contributes about 12.9 bits of entropy, so a 5-word passphrase lands around 65 bits before any added number.
Either way, the generator shows you the resulting entropy so you're not guessing at strength.
The short version
- Don't paste a password directly into chat, email, or a ticket — it lives on in history and backups long after you've forgotten it.
- Encrypt it first with the Secret Note tool: AES-256-GCM, PBKDF2-derived key, nothing uploaded.
- Send the encrypted block and the password over separate channels — that split is what actually protects the secret.
- Generate the wrapper password with a CSPRNG-based password generator rather than reusing one you already know.
Ready to send one? Encrypt your secret note now — it runs entirely in your browser, and the live monitor on the page shows exactly zero bytes leaving it.