Encrypt text online

What is text encryption?

To encrypt text is to transform it so that only someone holding the right key can read it back. This tool does that with a passphrase you choose: you type a message, you type a passphrase, and you get a single line of text that is meaningless to anyone who does not have the passphrase. Paste that line back in later with the same passphrase and the original message returns exactly.

The cipher is AES-256-GCM, which is the standard choice for this job and is built into every browser. GCM is an authenticated mode, which matters more than it sounds: it does not merely hide the message, it also detects any change to it. Flip a single bit of the encrypted text and decryption refuses outright rather than handing back plausible-looking rubbish.

A passphrase is not a key, though, and the gap between them is where most of the interesting engineering lives. AES-256 wants a uniformly random 256-bit key; you want to type something you can remember. Bridging those two is the job of a key derivation function, and on this page that is PBKDF2 with 600,000 iterations of HMAC-SHA256 — the figure OWASP publishes in its Password Storage Cheat Sheet. Everything runs in your browser through the Web Crypto API. Nothing is uploaded, and there is no account.

How to use it

1. Choose Encrypt and type your message. Any text works — accents, Arabic, Chinese and emoji all survive the round trip, because the text is converted to UTF-8 bytes before the cipher ever sees it.
2. Enter a passphrase, then press Encrypt. There is a short pause while the key is derived; that pause is the security feature, and the tool reports how many milliseconds it actually took on your machine. Copy the resulting line and store or send it however you like.
3. To read it back, switch to Decrypt and paste the line in. Enter the same passphrase and press Decrypt. If it fails, the tool will say so but cannot tell you whether the passphrase was wrong or the text was altered — those two are genuinely indistinguishable, for a reason explained below.

The browser offers exactly one password KDF, and it is the one OWASP ranks last

This is the part most tools leave out, and it is worth stating plainly rather than dressing up. The W3C Web Cryptography API — the specification behind the crypto built into browsers — defines exactly four algorithms capable of deriving a key: ECDH, X25519, HKDF and PBKDF2. Two of those are key agreement between parties, and HKDF is designed for input that is already uniformly random, which a human passphrase emphatically is not. That leaves one: PBKDF2.

Meanwhile OWASP's Password Storage Cheat Sheet ranks the password hashing functions in a clear order of preference: Argon2id first, then scrypt, then bcrypt, and PBKDF2 fourth. It recommends PBKDF2 specifically for the case where FIPS-140 compliance is required, which is a regulatory reason rather than a cryptographic one. So the browser hands a web page precisely one option, and it is the option OWASP lists last.

The reason PBKDF2 sits at the bottom is that it is not memory-hard. Its work is pure computation, which is exactly the shape of work that a graphics card does thousands of times in parallel. Argon2id was designed to be deliberately expensive in memory as well as time, so that an attacker's hardware advantage shrinks. Getting Argon2id into a browser means downloading a WebAssembly build of it, which is a real cost paid on every visit for a page that may be used once.

So this tool uses PBKDF2 at OWASP's published figure, and says so, rather than implying that the choice was made on merit. If you are protecting something where the difference between PBKDF2 and Argon2id matters to you, that is a signal you should be using a program you installed rather than a web page — which is the same conclusion the limitations section reaches by a different route.

What 600,000 iterations actually buys: about 19 bits

Every tool in this category advertises its iteration count, and the number is meant to sound reassuring. Here is the part that is almost never printed next to it. Running the derivation 600,000 times multiplies an attacker's cost per guess by 600,000. Expressed the way cryptographic strength is normally expressed, that is a factor of two raised to the power 19.19 — so the entire iteration count is worth about nineteen bits.

Nineteen bits is a real contribution and it is not a large one. It means an attacker who could try a billion passphrases per second against an unprotected hash is reduced to trying roughly seventeen hundred per second. That is a serious obstacle to someone guessing a passphrase drawn from a large space, and almost no obstacle at all to someone working through a list of common passwords. The iteration count moves the line; the passphrase decides which side of it you are on.

The practical consequence is that the passphrase supplies essentially all of the security, and the iterations supply a fixed bonus of about nineteen bits on top. A four-word passphrase chosen at random from a large word list is worth far more than that bonus by itself. A short passphrase, or one that appears in any breach list, is still a short passphrase after 600,000 iterations — the work factor multiplies the cost of each guess, but it does not increase the number of guesses an attacker has to make.

The tool shows you the derivation time on your own machine for the same reason. Your browser and your hardware, not a figure measured somewhere else, decide what those iterations actually cost, and seeing the number makes the trade concrete rather than abstract.

The output describes itself, on purpose

The encrypted text is a single line with five dot-separated fields: a version marker, the iteration count, the salt, the nonce and finally the ciphertext with its authentication tag. The three binary parts are written in base64url so the whole thing survives being pasted into an email, a chat window or a URL without anything mangling it.

The iteration count is inside the output deliberately. OWASP revises its recommended figure upward as hardware improves — it has moved several times and will move again. A tool that hardcodes the count in both the encrypting and decrypting paths quietly loses the ability to read its own old output the day it updates that constant. Because the count travels with the ciphertext, text encrypted today will still decrypt years from now, when the default has moved on. The same applies to the salt and the nonce: both are random, both are needed to decrypt, and both are therefore recorded rather than recomputed.

That design has a sharp edge worth naming, because it is the kind of thing a self-describing format quietly introduces. If the iteration count comes from the pasted text, then the pasted text controls how much work your browser does before any passphrase is even checked — and a hostile blob claiming a trillion iterations would simply freeze the tab. The tool therefore caps the count it will accept, and refuses anything beyond it rather than starting the work.

Two more details are visible in the breakdown panel. A fresh random salt and a fresh random nonce are generated for every single encryption, which is why encrypting the same message twice with the same passphrase produces two completely different outputs — that is correct behaviour, not a glitch. And the authentication tag is 128 bits, exactly 16 bytes of overhead. Web Crypto permits tags of 32, 64, 96, 104, 112, 120 or 128 bits and defaults to 128; the shorter ones are meaningfully easier to forge, so this tool pins the maximum rather than relying on the default.

Honest limits

Encryption performed in a web page does not protect you against the web page. The JavaScript doing the work is served fresh by this site every time you load it, and if that script were ever malicious — through a compromise, a bad dependency, or a deliberate change — it could read your passphrase and your plaintext before either was encrypted. You cannot verify from the outside that it has not. This is not a flaw in AES or in this implementation; it is the structural condition of doing cryptography in a page delivered by someone else, and it applies equally to every browser-based encryption tool, including the ones that do not mention it.

What this tool genuinely gives you is protection for a message that is sitting somewhere else. If you encrypt a note and paste it into an email, a shared document, a notes app or a chat log, anyone who later obtains that text without the passphrase cannot read it. That is a real and common threat model, and the tool serves it well. What it cannot do is protect you from a determined party who is specifically targeting you, because such a party has better options than attacking the ciphertext. For that work, use an audited program you installed yourself and can verify.

A failed decryption cannot tell you why it failed. AES-GCM verifies the authentication tag and reports one single result for any mismatch, and the specification defines exactly one error for it. A wrong passphrase and a single altered character produce the identical outcome, and no amount of care in the implementation can separate them — the information simply is not there. The tool says so rather than guessing, because a tool that claimed to know would be inventing the answer.

There is no password recovery, and there cannot be one. Nothing about your passphrase is stored anywhere, which is precisely why the encryption is worth anything; the unavoidable consequence is that losing the passphrase means losing the text permanently. Finally, this encrypts text and not files — the message goes through the browser as text, so binary attachments are outside what this page does.

Why is it free?

Because it costs nothing to run. Every part of this — the key derivation, the encryption, the decryption — happens inside your own browser using the Web Crypto API that is already there. No library is downloaded, no text is sent anywhere, and no server sees your message or your passphrase, because no server is involved at all.

So there is no account, no sign-up, nothing held back behind one, and no watermark. The cipher is the browser's own AES-256-GCM, the key derivation figure comes from OWASP's published guidance, and the container format is documented above so that the output is not hostage to this website continuing to exist.