Encrypt & Decrypt Text Online

Check a local encrypted text round trip

Choose a mode for the right purpose

Text Encryptor and Decryptor has three different mechanisms. AES-GCM derives an AES key from a passphrase and provides authenticated encryption through the browser's Web Crypto API. RC4 is a legacy compatibility mode, and Caesar shift is an educational letter substitution. These are not interchangeable security choices. Use a maintained security product for high-stakes secrets, shared access management or long-term records. This utility does not manage recipients, provide key escrow or recover a forgotten passphrase. Its value is a small, inspectable local text workflow with explicit parameters and a packet you can retain and test.

Worked example: test a disposable AES message

Enter Crate 42: shelf B7 as the raw text, choose AES-GCM and supply a disposable passphrase that you do not use elsewhere. Encrypt the text and retain the complete result. Switch to Decrypt Text, paste that result and enter the same passphrase. The expected plaintext is exactly Crate 42: shelf B7. Repeat with a short Unicode message to confirm that your intended characters survive. Encrypting the same message twice normally produces different packets because the salt and IV are generated anew. Different ciphertext does not imply that the text or passphrase changed; successful decryption is the relevant round-trip check.

Keep the packet together

The existing packet format is an outer Base64 string containing JSON fields named salt, iv and ct. The first two fields encode a sixteen-byte salt and a twelve-byte initialization vector. The ct field contains ciphertext plus the authentication tag. PBKDF2 uses SHA-256 and one hundred thousand iterations to derive a 256-bit AES-GCM key. These details describe this implementation rather than a claim that every encryption tool uses the same envelope. The result is ordinary Base64, not a URL-safe token. Do not remove padding, rename fields or paste only the ciphertext field if you want this page to decrypt it.

Passphrase loss and authentication failures

The passphrase is not stored in the output packet. Keep it through a separate, appropriate channel; placing it beside the encrypted message defeats much of the reason to encrypt. An incorrect passphrase, damaged packet or modified authentication tag should fail decryption and clear stale output. The error cannot reliably distinguish all of those causes. Compare against a known copy and retry without changing the original. A successful result establishes that the packet authenticated under the derived key; it does not identify the human who supplied that key. Length alone does not make a predictable password strong, and the tool cannot guarantee the safety of your chosen passphrase.

Caesar shifts include zero and negative values

Caesar mode shifts ASCII A to Z and a to z while leaving other characters unchanged. With shift three, Crate 42 becomes Fudwh 42; decrypting reverses that shift. Shift zero leaves the text unchanged. A shift of twenty-six also wraps to zero, and minus one shifts A to Z. Enter a whole number between minus one million and one million; fractional or partly numeric strings are rejected. This mode does not encode every writing system or protect a secret from an interested reader. Use its predictable transformations for demonstrations, simple puzzles or checking wraparound behavior, not for confidential information.

RC4 is deliberately limited legacy handling

The RC4 option works with Latin-1 text and keys in this implementation, then represents its binary result as Base64. Characters outside that range are rejected instead of silently producing a corrupted packet. This mode does not authenticate its output: an incorrect key can yield meaningless text without an authentication error. Do not interpret any displayed result as proof of integrity. AES-GCM is the appropriate option here for ordinary Unicode round trips. A packet produced by another RC4 tool may use different character encoding or framing even when both interfaces say RC4. Test a small known fixture before attempting any compatibility conversion.

Bounds and browser requirements

Plaintext entry is bounded to one hundred thousand UTF-16 characters; encrypted packet input allows six hundred thousand, and a key allows one thousand. The larger packet cap accommodates encoding overhead rather than inviting unlimited data processing. Byte length differs from UTF-16 length for many Unicode characters. AES-GCM requires a browser with Web Crypto support in a suitable secure context. If processing is unavailable, the page reports a failure instead of fabricating a result. This is a text utility, not a streaming file-encryption application. For large documents or automated pipelines, choose software designed for that workload and preserve its documented file format.

Copy, download and changing a draft

Copy Result requests clipboard access and reports a failure if the browser denies it. The visible output can still be selected manually. Download requests a plain-text file containing the current result; check the browser's downloads list rather than assuming the file reached a particular folder. Input, passphrase, mode or direction changes invalidate the old output, so you do not accidentally share a packet from an earlier draft. A request that finishes after the draft has changed must not replace the current work. Test decryption of a saved sample before deleting your original plaintext, and keep backups appropriate to the sensitivity of the data.

Processing and practical privacy

Key derivation and text transformation run locally without a text-processing endpoint. Page assets and the surrounding site's normal services still use network access. A downloaded plaintext file, clipboard history, browser extension or screenshot can expose information even when the encryption calculation itself stays local. The tool does not erase your operating system clipboard, securely wipe memory or verify that your computer is uncompromised. Close the page when finished and follow your own device and retention practices. Keep the description of local processing separate from a guarantee of overall security; the actual workflow includes the device, passphrase handling and any exported copies.

References: Web Crypto key derivation, AES-GCM parameters

Guide published by . View our publishing information and contact details.