Free · runs in your browser

Text Encrypter Decrypter

Text Encrypter Decrypter. Type a passphrase and your text to instantly encrypt or decrypt it with AES-256-GCM. The base64 encoder decoder is the fastest way to move between formats without doing the conversion by hand.

Your values
Mode

AES is the modern standard. 3DES is only for older systems that require it. The XOR cipher shows how a key scrambles text, but it is not secure.

GCM adds an authentication tag, so a wrong passphrase or altered text is rejected. CBC, CTR and ECB only hide the content.

Decrypt with the same key size you used to encrypt.

Encrypting: any text, JSON or config value. Decrypting: paste the Base64 output exactly as produced (for XOR, the comma-separated numbers); text encrypted by the earlier version of this tool (AES-256-GCM) still decrypts. Nothing is sent to a server.

Use the identical passphrase, cipher, mode and key size to decrypt. There is no way to recover text if the passphrase is lost.

Result

Result
—
Details
—
  • No account, no logging
  • Open formulas explained below
  • Works offline once loaded

Paste your message into this free text encrypter decrypter, add a passphrase, and get back unreadable ciphertext that only the same secret key can reverse. It runs AES-256 inside your browser, so you can encrypt and decrypt text instantly while your data never leaves your device.

How This Text Encrypter Decrypter Works

Encryption is the process of turning a readable message into an unreadable form so unauthorized parties cannot make sense of it. The readable input is called plaintext, and the scrambled output is called ciphertext. A text encryption and decryption tool applies a mathematical algorithm plus a secret to move between the two, and only someone holding the correct secret can move back.

You choose a custom secret key in the form of a passphrase, but it is not used as the key directly. The tool stretches it into a 256-bit key with PBKDF2 and SHA-256, repeating the hashing for 600,000 iterations so that guessing passphrases becomes slow and expensive for an attacker. A random salt is added every time, which is why the same message encrypted twice gives two different results.

Encrypt Text Online in Four Steps

  1. Keep AES-GCM selected, because it is the recommended mode for any new encrypted value.
  2. Paste or type the message you want to protect into the input box.
  3. Enter a long passphrase that you have not used anywhere else.
  4. Click the Encrypt button, then copy the result or create a share link to send it.

Everything between those steps happens locally through the Web Crypto API. Your text, passphrase and results are never transmitted, uploaded or logged, and there is no sign-up or account to create. That keeps the whole exchange secure on your own device.

Text Decryption With the Same Passphrase

To reverse the process, paste the encrypted output into the decrypt tool, type the identical passphrase, and click Decrypt. The tool reads the salt and the initialization vector from the front of the ciphertext, rebuilds the key and returns the decrypted text, your original message. Whether you need to encrypt or decrypt, the same passphrase and settings must be used on both sides. If even one character of the passphrase is wrong, or one character of the ciphertext was changed, decryption fails loudly instead of returning garbage.

Text Encryption With AES-256: The Algorithm Explained

The Advanced Encryption Standard, or AES, is a symmetric block cipher standardized by NIST. Symmetric means a single key does both jobs: the key that locks the message also unlocks it. A block cipher works on fixed 128-bit chunks of data, which is why short messages are padded or processed in a counter mode. Every encryption algorithm trades speed against strength, and AES strikes a strong balance. It secures TLS connections, digital communication, disk encryption, banking apps and cloud storage, and it has withstood decades of public attacks. Need to use the text to nato alphabet converter? There is a free, no-sign-up tool for exactly that.

AES-GCM vs AES-CBC

Both modes protect your text, but they behave differently once something goes wrong. AES-GCM is an authenticated mode: it adds an authentication tag, so any tampering with the ciphertext is detected before a single character is returned. AES-CBC only hides the content, and it needs a separate message authentication code to catch changes. Older options such as DES and 3DES survive only for legacy data, because DES uses a 56-bit key that modern hardware can break. Choose CBC only when another system you work with demands it, and treat it as legacy compatibility rather than a first choice.

Key Size and Key Management

A longer key means more possible combinations for an attacker to try. AES-256 uses a 256-bit key, which is far beyond brute force with any foreseeable hardware, and AES-128 remains acceptable for most needs. Yet key size is only half the story. Strong key management matters just as much: never hardcode a key in source code, never keep it beside the encrypted data, and rotate it on a schedule. In production, a KMS or an HSM is the proper home for keys, and key rotation should be routine.

Worked Example: Encrypt and Decrypt Text Online

Suppose you want to send a colleague a meeting note. The plaintext is Meet Priya at Gate 14 by 6:45 pm, which is 32 characters and therefore 32 bytes. After you run it through the encrypter with a passphrase, the tool assembles four parts in a fixed order: a 16-byte random salt, a 12-byte initialization vector (the IV), the encrypted bytes, and a 16-byte authentication tag. AES-GCM does not need padding, so the encrypted bytes are exactly as long as the plaintext.

Some tools wrap the salt, IV and settings in a versioned envelope so one string carries everything needed to decrypt it. The binary result is then written as Base64 so it can travel through chat, email or a JSON field. Base64 turns every 3 bytes into 4 printable characters:

$$\text{bytes} = 16 + 12 + n + 16 \qquad \text{Base64 length} = 4 \times \left\lceil \frac{\text{bytes}}{3} \right\rceil$$

With \(n = 32\), the total is \(16 + 12 + 32 + 16 = 76\) bytes, and \(4 \times \lceil 76 \div 3 \rceil = 4 \times 26 = \)104 characters of output. That is why encrypted text always looks longer than the message you started with. Paste those 104 characters back in with the same passphrase and the original 32 characters return exactly.

  • Input: 32 bytes of plaintext and one passphrase.
  • Overhead: 44 bytes for the salt, IV and tag, a fixed cost whatever the message length.
  • Output: 104 Base64 characters you can copy, store or send.

A Bookkeeper Uses the Text Encryption Tool to Send Bank Details

Marta, a freelance bookkeeper, has to give a new client the bank details for invoice INV-2291, and the client only answers email. A plain email would leave the account number readable in two inboxes and a mail server, so she opens the encrypter instead.

She types the one-line message Acct 40718826 Sort 20-45-17 Ref INV-2291, which is 40 characters, and picks AES-GCM. For the passphrase she chooses four unrelated words she has never used for an account. She clicks Encrypt, and the tool reports 84 bytes (16 salt, 12 IV, 40 of encrypted text, 16 tag), written out as a 112-character Base64 string, exactly what the size formula predicts: \(4 \times \lceil 84 \div 3 \rceil = 112\).

Before sending anything, she pastes the 112 characters into the decrypt tool with the same passphrase and confirms the 40 original characters come back. She then changes the last letter of the passphrase and tries again; decryption fails, which proves the authentication tag is working as NIST describes for GCM. The 600,000 PBKDF2 iterations also match the figure OWASP lists for SHA-256 key derivation.

The encrypted string goes in the email. The passphrase goes by phone call, a separate channel, so nobody who reads the mailbox holds both halves. The result tells her the exchange is safe to complete, and her next action is simple: once the client confirms the first payment arrived, she deletes both messages.

Encryption and Decryption vs Hashing and Encoding

People often mix up three different operations. Encryption is reversible with a key. Hashing produces a fixed-length, one-way fingerprint that cannot be turned back into the original, so it suits password storage with bcrypt or Argon2 and never suits data you need to read later. Encoding, such as Base64, only changes how data is represented and gives no secrecy at all, since anyone can decode it. If you need to keep a note private, use encryption; if you need to verify a password, use a hash; if you need text-safe transport, use encoding.

Why a Caesar Cipher Is Not Enough for Text Encryption

The tool above uses AES rather than any classical method, and the history shows why. The Caesar cipher is a simple substitution that applies a fixed shift to every letter, moving it a set number of places, and the Vigenère cipher improved on it with several alphabets. The scytale wrapped a strip around a rod, and the Enigma machine mechanized the idea during World War II. Every one of them falls to patterns in the language. A stream cipher such as RC4 and the old DES standard also aged badly, and DES is no longer approved for new work, which is why ChaCha20, Blowfish alternatives and AES replaced them, and why RSA is kept for exchanging keys rather than bulk data. DES, once the standard, was replaced by AES for stronger security. That gap is why this encrypter relies on a modern, vetted algorithm. Looking ahead, lattice-based cryptography is being developed because quantum computers may eventually threaten some current methods.

Encryption Best Practices for Free Online Text Encryption

A free browser tool is fine for personal notes, tests and light professional use, as long as you follow a few habits. For credentials or production data, use a dedicated secrets manager instead.

  • Stick to AES-256 and AES-GCM, and avoid custom or home-made ciphers.
  • Use a passphrase of several unrelated words, never a single dictionary word.
  • Share the passphrase through a separate channel from the encrypted text.
  • Test the result by decrypting it yourself before you send it.
  • Do not encrypt passwords you are verifying; hash them instead.
  • Store sensitive data, such as keys, in a password vault, because a lost secret key cannot be recovered.

Security is only as strong as the weakest step, so treat the security of every message as a chain, whether that is the passphrase, the channel, or the device you decrypt on. Following OWASP guidance on key handling and avoiding outdated algorithms keeps privacy intact and your data secure, and reviewing the implementation regularly guards against newly found vulnerabilities.

Who Uses a Text Encryption and Decryption Tool

Developers use it for testing an encryption flow or checking what an API payload looks like once protected. Writers and managers use it to protect messages and notes, JSON, YAML and configuration values before pasting them into a ticket. Teams also paste in API payloads when they need to check a secure handoff. Anyone who must encrypt & decrypt text online without installing software can do it here, and students use it to see how an algorithm turns a string into ciphertext and back. Because the output is plain Base64, it fits anywhere text fits, including chat, email and logs.

Frequently Asked Questions

What format is the encrypted output?
A single Base64 string containing the random salt (16 bytes), the random IV/nonce (12 bytes), and the AES-256-GCM ciphertext (which includes its own authentication tag) concatenated together -- self-contained, so you only need to copy one value to decrypt later, with no separate salt or IV to track.
Why does decryption need the exact same passphrase?
The passphrase is run through PBKDF2 (250,000 iterations, SHA-256) together with the salt stored in the encrypted output to derive the actual AES-256 key -- get the passphrase even slightly wrong and the derived key is completely different, so decryption fails outright rather than producing garbled text (GCM's built-in authentication tag catches this and reports a clear error instead).
Why 250,000 PBKDF2 iterations?
It's a deliberate slowdown that makes brute-forcing a weak passphrase significantly more expensive for an attacker, while still completing in a fraction of a second for a legitimate user with the correct passphrase -- roughly in line with current OWASP recommendations for PBKDF2-SHA256.
Is this the same as a password manager's encryption?
It uses the same well-established building blocks (AES-256-GCM, PBKDF2) that many password managers rely on, but this tool is a simple one-off encrypt/decrypt utility, not a full vault -- there's no key storage, no session, no sync. Use it for sharing a short secret text securely, not as a replacement for dedicated encrypted storage.
Is my text or passphrase sent anywhere?
No. Both encryption and decryption happen entirely in your browser using the Web Crypto API -- nothing is transmitted, logged, or stored. Reload the page and everything is gone.

About the author

Vinitha Pu

Founder and designer

Vinitha Pu is a graphic designer based in Palakkad, Kerala, who builds free, privacy-friendly browser tools. She studied Textile and Apparel Design at Avinashilingam University and completed a C-Tech in Graphic Design at Image Creative Education in 2025. She designs, builds and maintains the password generators, strength checkers, hash tools and security calculators on PasswordHive.

  • Content author: Vinitha Pu
  • Fact checked by: Vinitha Pu. Each tool's output is checked against official test vectors or a reference implementation, and every strength and crack-time figure against the formula it uses, before it goes live.
  • Published Updated