Text Encryptor & Decryptor

Introduction

Readable text becomes ciphertext when a cipher and key transform it into bytes that should look useless to anyone without the password. That matters for copied notes, draft messages, recovery codes, API snippets, or any short text you need to move or store without leaving it exposed in plain language. This tool lets you encrypt or decrypt that text with a password while keeping the main choices visible: algorithm, key derivation method, salt, IV or nonce, output format, and integrity signals.

The scope is wider than a basic AES button. You can work with AES-GCM, AES-CBC, AES-CTR, AES-CFB, AES-OFB, DES-CBC, TripleDES-CBC, RC4, and Rabbit. Passwords can be stretched with Argon2id or PBKDF2-SHA256, text can be loaded from a local .txt file, and the result can be wrapped as a JSON envelope, a raw IV-plus-ciphertext string, a raw binary file, or an OpenSSL-style Salted__ payload for AES-CBC compatibility.

The encryption and decryption happen in the browser rather than being posted to a helper service. That reduces one obvious exposure point, but it does not make the whole workflow harmless. Passwords still need to be strong, copied ciphertext can still leak, and downloaded files, salts, IVs, and JSON envelopes still deserve the same care you would give to any sensitive export.

This is a good fit when you need to protect a short piece of text, reproduce another password-based format, or investigate why a legacy ciphertext will not open. It is not a substitute for key management, secure messaging, device hardening, or a password manager. If you need long-term secret storage or team-wide secret rotation, those problems sit outside the boundaries of a text cipher tool.

Technical Details

Each run starts with UTF-8 text bytes and a password. The password is stretched with either Argon2id or PBKDF2-SHA256, using a salt to keep identical passwords from producing identical derived keys. The derived bytes are then split into the encryption key and, when needed, a separate integrity key. If you leave the salt or IV fields blank for a new encryption run, the tool generates random values for you. During decryption, those values must match the original run exactly.

AES-GCM is the authenticated option in the list. It uses a 12-byte nonce in this tool, adds a 16-byte authentication tag to the encrypted output, and can bind optional associated data that stays unencrypted but must match on decrypt. The AES-CBC, CTR, CFB, and OFB variants use 16-byte IVs. DES-CBC and TripleDES-CBC use 8-byte IVs. Rabbit also uses 8 bytes, while RC4 ignores the IV field. Padding applies to block modes such as CBC, but not to CTR, RC4, Rabbit, or AES-GCM.

Plain text
  -> UTF-8 bytes
  -> password + salt -> derived key material
  -> key + IV or nonce [+ AAD for AES-GCM]
  -> ciphertext
  -> Envelope / Raw / Raw Binary / OpenSSL-style output

Output format changes what travels with the ciphertext. Envelope mode stores the parameters in JSON so the decrypting side can see the algorithm, KDF settings, salt, IV, encoding, ciphertext, and any integrity value carried with the payload. Raw mode is smaller because it only joins IV or nonce bytes with ciphertext before encoding the result as Base64 or hex. Raw Binary does the same join but keeps the result as bytes for file download. The OpenSSL-compatible branch is narrower by design: it only works with AES-CBC, derives the key and IV with PBKDF2-SHA256, uses an 8-byte salt, and wraps the ciphertext with the classic Salted__ prefix.

The results area is built for inspection rather than just export. The main output tab shows ciphertext or recovered plain text. Result Metrics breaks out the algorithm, KDF, salt, IV or nonce, tag length, ciphertext length, output size, and HMAC status when present. Size Comparison turns those byte counts into a chart you can export as PNG, WebP, JPEG, or CSV. The JSON tab keeps a structured summary of the run so you can compare settings later without reading the whole ciphertext by eye.

Current standards explain why the options do not all carry the same weight. NIST treats Galois/Counter Mode as an authenticated mode, while older confidentiality modes such as CBC, CTR, CFB, and OFB do not give you that same built-in tamper check. Argon2id is the modern memory-hard choice for password derivation, while PBKDF2 remains the compatibility workhorse. DES and TripleDES stay in the menu for older data flows, but they are legacy options rather than fresh defaults; NIST announced that applying new protection with TDEA became disallowed after December 31, 2023.

Everyday Use & Decision Guide

If you want the cleanest default for new password-based text protection, start with AES-GCM. It encrypts the text and checks integrity in one mode, so tampering or parameter drift is more likely to fail clearly instead of producing garbage text. Choose one of the older AES modes only when you need to match an outside system or test how a legacy payload was built. DES, TripleDES, RC4, and Rabbit should be treated as compatibility lanes, not as your first stop for new notes.

Pick the KDF based on who has to read the result later. Argon2id is the better fit when both sides can use the same modern settings and you want slower password guessing attacks. PBKDF2-SHA256 is the better fit when the receiving side already expects PBKDF2, when you are reproducing an older workflow, or when you specifically need the OpenSSL-style path. In either case, the strength of the result still depends heavily on the password itself. A short, guessable password undermines every algorithm in the list.

Choose the output container according to how much metadata you are willing to carry yourself. Envelope mode is easiest to reopen because it keeps the settings with the ciphertext. Raw mode is compact, but you must preserve the algorithm, KDF settings, salt, IV or nonce, padding choice, and any AAD outside the exported string. Raw Binary is the same idea in file form. OpenSSL Salted__ is the narrow interoperability option for AES-CBC data when you need the classic salted prefix that old command-line workflows expect.

Associated data deserves restraint. Use it only when both sides can reproduce the exact same bytes during decryption, because even a small mismatch will break AES-GCM authentication. The same discipline applies to HMAC checks in envelope workflows. If the integrity check fails, stop there. Do not treat a bad HMAC or authentication failure as a partial success.

The built-in tabs support practical decision making. The output tab tells you what will actually be shared or stored. Result Metrics confirms the supporting parameters. Size Comparison helps when you are trading readability against compactness. The JSON tab is useful when you need a clean record of the run for testing, debugging, or future recovery.

Step-by-Step Guide

1. Paste the text or load a local .txt file, then choose whether you are encrypting new text or decrypting an existing payload.
2. Select the algorithm that matches your goal. AES-GCM is the normal starting point for new work. Pick another mode only when compatibility or investigation requires it.
3. Enter the password, then open Advanced if you need to set the KDF, iteration or memory cost, salt, IV or nonce, padding, associated data, HMAC option, or output format.
4. Leave salt and IV fields blank for a fresh encryption run unless you have a reason to supply fixed values. For decryption, make sure every required parameter matches the original run exactly.
5. Run the operation and review the output together with Result Metrics before sharing or storing anything.
6. Export what you need: the text output, a downloaded binary, the metrics table as CSV or DOCX, the size chart image or CSV, or the JSON summary.

Interpreting Results

A success banner only means the tool completed the requested action with the inputs you gave it. The real interpretation lives in the details below it. Check the algorithm, KDF, salt, IV or nonce, encoding, padding, output size, and tag length. If those fields do not match the workflow you thought you were using, the ciphertext may still be useless even though the screen looks tidy.

Integrity failures are the clearest warning signs. In AES-GCM, a wrong password, wrong nonce, wrong associated data, or altered ciphertext usually ends in decryption failure. In envelope workflows that carry HMAC, a bad HMAC means the wrapped parameters and ciphertext do not line up with the expected integrity key. Treat either result as a stop signal, not as something to work around.

Raw output needs extra skepticism because it carries less context. If decryption fails there, the problem may not be the password at all. Missing salt, the wrong IV length, the wrong padding setting, or a mistaken choice between Base64 and hex can all look like a bad password when the real issue is missing metadata. That is why the metrics table matters so much during troubleshooting.

The size chart is useful for format selection. A larger envelope is not wasted space if it saves you from losing the metadata needed for future decryption. A smaller raw string is only better when you already have a reliable place to store the missing parameters. When binary output is selected, remember that the preview is intentionally shortened and the downloaded file holds the full byte sequence.

Worked Examples

Protecting a short note for a coworker who shares the password

A project manager needs to send a brief incident note that should not sit in plain text in chat history. AES-GCM with Argon2id and Envelope output is a sensible choice here. The recipient gets one self-contained payload, and the attached metadata makes later recovery much easier than a bare ciphertext string.

Checking why an old OpenSSL-style payload will not decrypt

A support engineer receives a Base64 string that starts with the classic salted OpenSSL prefix. The OpenSSL-style branch in this tool narrows the problem quickly because it expects AES-CBC, PBKDF2-SHA256, and the embedded 8-byte salt layout. If decryption still fails, the likely causes are the password, the wrong AES key size selection, or a mismatch between how the original data was produced and how it was described.

Choosing between compact output and easier recovery

A developer needs encrypted test fixtures for an internal workflow. Raw hex output is attractive because it is compact and easy to paste into text-based fixtures, but it also means the salt and IV must be stored somewhere else. Running the same text through Envelope and Raw output, then comparing the size chart and metrics, makes that tradeoff visible before the format gets locked into tests.

FAQ

Glossary

Ciphertext

The encrypted byte sequence or encoded string produced from the original text.

KDF

Key derivation function. It turns a password and salt into cryptographic key material.

IV / nonce

A per-message value that helps keep separate encryptions from producing the same output under the same password-derived key.

Associated data

Extra bytes that AES-GCM authenticates without encrypting. They must match exactly during decryption.

HMAC

A keyed integrity check used to detect tampering or mismatched parameters when the workflow carries one.

Salted__

The classic OpenSSL prefix used in certain salted password-based ciphertext formats.

References

• RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications
• RFC 8018: PKCS #5 Password-Based Cryptography Specification Version 2.1
• NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation
• NIST SP 800-38D: Recommendation for Galois/Counter Mode (GCM) and GMAC
• OpenSSL enc documentation
• NIST notice on withdrawing SP 800-67 Rev. 2 and the TDEA transition