Encrypt a message you can paste anywhere
Turn text into a block you can send through chat, email or a ticket, readable only by someone with the password. The same AES-256-GCM container the file tool uses, wrapped so it survives being pasted.
Encrypt
And they need it by some route other than the one carrying the message — sending both through the same chat window protects against nothing. Say it aloud, use a different app, or agree it in advance. A forgotten password cannot be recovered by anyone, including us.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
What the block contains
Exactly the same container the file tool writes, Base64url-encoded and wrapped in marker lines. A message encrypted here can be saved and opened as a file, and a small file can be armoured and pasted as a message — there is no second cipher, only a second wrapping.
Base64url rather than ordinary Base64 because + and / get escaped the moment the text touches a URL, and a message that changes shape in transit is a message that no longer decrypts. The block is wrapped at 64 characters for the same reason: mail clients rewrap long lines, and a fixed short width means they have nothing to rewrap.
The decoder is deliberately forgiving about what surrounds the payload — marker lines or not, one line or many, with or without a mail client's > quoting down the left — and strict about the payload itself.
What this protects against, and what it does not
It protects the content of the message from anyone who sees the block without the password: the chat provider, the mail server, someone reading over a shoulder, anyone who obtains the logs later.
It does not hide that you sent an encrypted message, to whom, or when. The block is obviously encrypted and says so on the front. Metadata — who talks to whom, how often, at what times — is frequently more revealing than content, and nothing on this page touches it.
It does not protect the plaintext on either machine. You typed it into a browser and they will read it in one; anything with access to either device sees it regardless.
It is not forward secret. If the password is compromised later, every message ever encrypted with it can be read. A messaging app with proper key exchange gives you that property; a shared password cannot.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Getting the password to the other person
This is the hard part, and it is not one a web page can solve for you. If you send the password through the same channel as the message, anyone who can read one can read both, and you have gained nothing but effort.
Workable options: say it out loud in person or on a call; send it through a different service to a different account; agree a scheme in advance that produces the password without transmitting it. What does not work is emailing the password after the email.
For anything ongoing, a messaging app with real end-to-end encryption is a better instrument than this page. This is for the case where you need to send something through a channel you do not control and both ends can handle a password.
Related
File encryption for anything larger than a message, or the passphrase generator for a password worth using here.
Questions people actually ask
Is this a different cipher from the file tool?
No. It produces byte-for-byte the same container, Base64url-encoded and wrapped in marker lines. A message encrypted here can be saved and opened as a file, and vice versa. There is one cipher and two wrappings.
Why Base64url rather than ordinary Base64?
Because + and / get percent-escaped the moment the text touches a URL, and a block that changes shape in transit no longer decrypts. Base64url uses - and _ instead. The block is also wrapped at 64 characters so that mail clients, which rewrap long lines, have nothing to rewrap.
What if the paste gets mangled?
The decoder is forgiving about everything around the payload — marker lines or not, one line or many, a mail client's > quoting down the left, surrounding chatter — and strict about the payload itself. A paste that lost its ending is reported as incomplete rather than as a wrong password, because those call for different things.
How do I get the password to the recipient?
Not through the same channel as the message — if one can be read, so can the other, and you have gained nothing. Say it on a call, send it through a different service, or agree it in advance. This is genuinely the hard part and a web page cannot solve it for you.
Does this hide who I am talking to?
No. It protects the content of the message and nothing else. That an encrypted message was sent, to whom, and when are all visible, and that metadata is frequently more revealing than the content. Nothing on this page touches it.
Is it forward secret?
No. If the password is compromised later, every message ever encrypted with it can be read. Forward secrecy requires a key exchange that a shared password cannot provide — a messaging app with proper end-to-end encryption gives you that, and this page does not pretend to.
Does my message leave the browser?
No. Encryption and decryption happen in the page using your browser's own Web Crypto implementation. Nothing is uploaded, and nothing on this page reports to analytics.