Text Encryptor
Encrypt and decrypt text locally with AES-256-GCM using a passphrase. The key is derived from your passphrase and never leaves the browser, so the ciphertext is safe to share: nothing is ever uploaded.
How to use
- Encrypt mode is selected by default: paste the text you want to secure into the box. Chinese, English, emoji and any other characters are supported.
- Enter a passphrase and click "Encrypt". The output below is a three-part ciphertext: salt.IV.ciphertext: which you can copy and share freely.
- To recover the text, switch to Decrypt mode, paste the complete ciphertext, type the original passphrase and click "Decrypt".
- Encrypting the same text with the same passphrase always yields a different result (a fresh salt and IV each time). This is a normal AES-GCM security feature.
- This tool uses the Web Crypto API, so it requires a secure context such as HTTPS or localhost.
FAQ
Is my text or passphrase uploaded to a server?
Why does the same text produce a different result every time?
Can I decrypt if I forget the passphrase?
What are the dots inside the ciphertext?
How to use
- Pick the mode
Encrypt is selected by default on the chips at the top. Press Decrypt to recover text from ciphertext you received. Both modes share the same fields.
- Enter text and passphrase
Paste the content to protect; Chinese, English and emoji all work. Type a passphrase and press Show to double-check it before encrypting.
- Encrypt, then save
Press Encrypt to produce a three-part ciphertext in salt.IV.ciphertext form. Use Copy result or Download ciphertext to store or share it.
- Decrypt with the full string
Switch to Decrypt and paste the complete ciphertext with all three dot-separated parts. Enter the original passphrase; a missing part or a wrong one fails with a clear message.
- Guard the passphrase
The key is derived from your passphrase with PBKDF2 and never stored. Without it the text cannot be recovered, so keep the passphrase in a password manager.
About this tool
AES-256-GCM is a mainstream authenticated-encryption scheme. It encrypts your text and verifies integrity at the same time. A tampered ciphertext refuses to decrypt instead of returning corrupted data. This tool performs every step with the browser's built-in Web Crypto API. The passphrase is stretched with PBKDF2 using SHA-256 and 100,000 iterations. The text, passphrase and ciphertext never touch a server.
Use it to protect API keys, recovery codes or private notes stored in cloud drives or chat apps. It also works when two people must exchange a secret over an insecure channel. Agree on a passphrase, then post the ciphertext publicly; without the passphrase it reveals nothing. Fresh random salt and IV values mean identical input encrypts differently every time. That randomness blocks pattern analysis.
How it works
AES grew out of the Rijndael cipher designed by Belgian cryptographers, and NIST standardized it as FIPS 197 in 2001. Keys come in 128, 192 and 256-bit lengths, and this tool uses the strongest of the three. Both AES and GCM come from NIST: the GCM mode is specified in SP 800-38D and provides authenticated encryption. Counter mode does the enciphering, while an authentication tag computed over the Galois field guards integrity. Change a single ciphertext byte and the tag check fails, so decryption reports an error instead of returning tampered plaintext. Secrecy and tamper detection happen in one step.
A human passphrase must be stretched before it can serve as a key. This tool applies PBKDF2 from RFC 8018 with SHA-256 for 100,000 iterations, turning a memorable passphrase into a 256-bit key. That raises the cost of offline guessing by a large factor. The salt and the 12-byte IV are generated fresh on every run. The salt makes one passphrase derive different keys across ciphertexts, while the IV moves the counter start each time under the same key. Together they block precomputation and rainbow-table attacks. GCM is extremely sensitive to IV reuse, so an IV must never repeat under the same key.
When to use it
- Handing over credentials at offboarding
Offboarding means passing database passwords and admin accounts to a successor, and plain chat messages stay in history forever. Encrypt with a passphrase you agree on, then deliver that passphrase by phone or in person.
- Adding a lock to config-file secrets
Config files end up in repositories and distributed bundles. Encrypt the third-party credentials they contain and commit only ciphertext, then inject the passphrase as a manual step during deployment.
- Diagnosing why decryption failed
A failure does not automatically mean a wrong passphrase: GCM reports truncation and tampering in the same way. Paste the text elsewhere, check that all three parts survived, and only then revisit the passphrase.
Tips & tricks
- The same text with the same passphrase yields different ciphertext each run. The salt and IV are random, which is expected AES-GCM behavior, not a bug.
- The ciphertext is three Base64 sections joined by dots; copy and share all three intact, because any missing part makes decryption impossible.
- The page needs a secure context: if the Encrypt button stays unavailable, check that the address starts with HTTPS or localhost.
Things to watch
- Never keep passphrase beside ciphertext
Pasting the passphrase beside the ciphertext hands over the lock and the key together. That covers the same note, the same chat message and the same ticket. Store them on separate channels so one leak does not expose both halves.
- Weak passphrases cancel strong AES
One hundred thousand iterations slow brute force down but cannot rescue a passphrase like 123456. Dictionary attacks crack such passphrases in seconds. Algorithm strength and passphrase strength are separate budgets, so fund both.
- One passphrase for everything is fragile
Reusing a single passphrase across many ciphertexts is convenient until one leak burns all of them. Group by purpose, isolate what matters most, and keep the blast radius small.