If you need to send someone a message that only they can read β a password, a bank detail, a document reference, a private note β you can encrypt it in your browser in about thirty seconds. No account, no software, and nothing sent to a server. This page walks through it, then explains what the encryption actually protects you against.
Encrypting a message, step by step
-
Write or paste your message
Open the CrypClip encryption tool and type your message into the box. It never leaves the page β the text stays in your browser's memory and is not transmitted anywhere.
-
Choose a password
Pick something at least eight characters long. This is the single most important decision on the page: the encryption is only as strong as the password protecting it. A short or guessable password can be attacked offline by anyone who obtains the ciphertext. See our guide on sending messages safely for how to choose one.
-
Press Encrypt
Your message is replaced by a PGP block β a run of letters and numbers between
-----BEGIN PGP MESSAGE-----and-----END PGP MESSAGE-----. That block is the encrypted form. Without the password it is meaningless. -
Send it
You can copy the PGP block itself, or use the share link, which packs the same ciphertext into a URL after the
#symbol. A QR code appears too, when the message is short enough to fit one. -
Send the password separately
Not in the same email. Not in the same chat thread. The whole point is that someone who intercepts the message does not also get the key to it β which they do if both travel together.
How the other person reads it
If you sent the share link, they open it and the message is already loaded β they just enter the password. If you sent the raw PGP block, they paste it into the same tool and enter the password.
They do not need an account, and they do not need CrypClip specifically. The output is standard OpenPGP, so it also opens in GnuPG, Kleopatra, or any other PGP tool. That interoperability is deliberate: it means you are not dependent on this site continuing to exist.
What this actually protects against
It is worth being precise, because "encrypted" gets used loosely.
It does protect against
Anyone who reads the message in transit or at rest without the password. That includes the email provider storing it, the chat platform relaying it, someone reading over a shared inbox, and an attacker who later breaches whichever service it was sitting in. To all of them the message is an opaque block.
It does not protect against
A compromised device on either end. If there is a keylogger on your machine or theirs, encryption changes nothing β the message is plaintext before it is encrypted and after it is decrypted. It also does not protect a weak password from being guessed, and it does not hide the fact that you sent something.
Encryption protects data in transit and at rest. It does not protect endpoints. Any tool claiming otherwise is overselling.
Why do this in a browser at all?
Because the alternative β asking someone to install GnuPG, generate a keypair, and exchange public keys β is a real barrier when you need to send one thing to one person once. Most people who need to share a password securely today are not going to set up a keyring first, and the practical result is that the password gets sent in plain text instead.
A browser tool is a trade. You accept a slightly larger attack surface in exchange for something the other person can actually use. Whether that trade is right for you depends on who you are protecting the message from β we go through it honestly in CrypClip vs the GPG command line, and in the technical breakdown.