Text Encryptor & Decryptor
Encrypt or decrypt small text in your browser with AES-GCM, Argon2id or PBKDF2, portable envelopes, integrity checks, and byte-size evidence.{{ textTransformSummaryHeading }}
| Field | Value | Copy |
|---|---|---|
| {{ row.k }} | {{ row.v }} | |
| No details available. | ||
| Check | Status | Detail | Copy |
|---|---|---|---|
| {{ row.check }} | {{ row.status }} | {{ row.detail }} | |
| No checklist rows available. | |||
Introduction
Private text usually starts as something small enough to paste: a recovery note, temporary token, configuration secret, incident detail, or message that should not remain readable in chat history or a shared ticket. Encryption changes that readable plaintext into ciphertext, but the ciphertext is only one part of the record. A later decrypt needs the same password and the same technical recipe that created the encrypted bytes.
Password-based encryption adds a practical tradeoff. A memorable phrase is easier to exchange than a random key, yet it has to be stretched before it can safely feed a cipher. The salt keeps repeated passwords from deriving the same key material, while the IV or nonce keeps repeated messages from taking the same encryption path under that key. Losing one of those values can be just as final as losing the password.
Several terms matter before judging an encrypted text artifact:
- Plaintext
- The readable UTF-8 text before encryption, or the text recovered after decryption.
- Ciphertext
- The encrypted byte stream, often shown as Base64, hex, JSON, or a binary download.
- Salt
- A per-run value used by password stretching so the same password does not directly produce the same derived key.
- IV or nonce
- A per-message value required by the cipher mode. It is not secret, but it must be correct for decrypt.
Authenticated encryption is the safer default for new text because it protects confidentiality and detects changes to the encrypted bytes. AES-GCM, for example, can reject a wrong password, wrong nonce, changed ciphertext, or mismatched associated data instead of returning a plausible-looking string. Compatibility modes such as CBC, CTR, CFB, OFB, DES, TripleDES, RC4, and Rabbit may still be needed for older artifacts, but they need more caution because many do not authenticate the ciphertext on their own.
Container choice affects recoverability. A self-describing encrypted record can carry the algorithm, key-stretching settings, salt, IV or nonce, encoding, and ciphertext together. A raw string is smaller, but it depends on separate notes for the missing settings. OpenSSL-style salted text is familiar in command-line workflows and expects AES-CBC-compatible choices, an eight-byte salt, PBKDF2, and matching padding.
Text encryption is useful for one-off handoffs and recovery checks, not for every secret-management problem. A strong cipher does not manage access, rotate credentials, audit who decrypted a value, or clear plaintext from clipboards and shared devices. Long-lived team credentials still belong in managed secret storage with identity, recovery, and lifecycle controls.
How to Use This Tool:
Keep the operation, password, algorithm, and recovery metadata together. Most failed decrypts come from one mismatched setting rather than from damaged ciphertext.
- Paste content into Text, drag a small text file onto the field, or choose Browse text file. TXT, JSON, STENC, ENC, B64, LOG, and Markdown-style text files are accepted up to 2 MB.
- Set Mode to Encrypt for readable text or Decrypt for an envelope, raw ciphertext string, raw binary preview, or OpenSSL Salted__ text.
- Choose Algorithm. AES-GCM (256-bit) is the normal choice for new text. Use AES-CBC, AES-CTR, AES-CFB, AES-OFB, DES-CBC, TripleDES-CBC, RC4, or Rabbit only when a legacy payload requires it.
- Enter Password and choose KDF. Argon2id is the default for new envelopes, while PBKDF2-SHA256 is useful for compatibility and required for OpenSSL-style output.
- For encryption, choose Output format. Envelope (.stenc) is easiest to reopen, Raw and Raw Binary are compact, and OpenSSL Salted__ is for AES-CBC interop. Output encoding controls Base64 or hex when the format is text-based.
- Open Advanced only when you need exact repeatability. Leave IV / nonce hex and Salt hex blank for new encryption so fresh values are generated. If you fill them manually, use valid hex and record the values.
- Run Encrypt text or Decrypt text. If decrypt fails, check Cipher Details against the original password, algorithm, KDF parameters, salt, IV or nonce, padding, output encoding, HMAC, and AES-GCM associated data.
After a successful run, use Cipher Details for recovery notes and Security Checklist for a quick review of algorithm posture, password stretching, IV or nonce length, salt, integrity, and container portability.
Interpreting Results:
For encryption, the artifact tab is the value to copy or download. It may be a JSON envelope, a Base64 or hex raw string, a binary file preview, or an OpenSSL Salted__ artifact. For decryption, the artifact is the recovered plaintext, so treat the result field, copy button, and download as sensitive surfaces.
Cipher Details is the recovery record. Save the visible algorithm, KDF, KDF parameters, salt, IV or nonce, padding, associated-data length, output encoding, and format whenever the output does not carry those values by itself. Raw output is especially easy to make unrecoverable because the salt and KDF settings are not inside the raw string.
Security Checklist highlights likely risk, but it is not proof that the message is safe forever. Modern algorithm posture, Strong password stretching, a correct 12-byte AES-GCM nonce, and an authenticated integrity status are good signs. They do not verify password quality, recipient handling, device security, or whether the plaintext was already exposed elsewhere.
Cipher Byte Distribution explains size changes. Base64, hex, JSON metadata, IV or nonce bytes, salts, authentication tags, and binary downloads can all change the visible length. A larger envelope may be the better choice when portability matters because it keeps the decryption recipe with the ciphertext.
Technical Details:
Symmetric text encryption starts by converting the text to UTF-8 bytes. Password-derived key material is then created from the password, salt, and KDF cost settings. The selected cipher consumes the encryption key and IV or nonce, while compatibility modes can also derive a separate HMAC key for envelope integrity.
AES-GCM uses authenticated encryption with associated data. The plaintext is encrypted and a 128-bit authentication tag is included with the encrypted byte stream. Any associated data is authenticated but not hidden, and the same associated-data bytes must be supplied during decrypt.
Compatibility ciphers follow older mode rules. AES-CBC, DES-CBC, and TripleDES-CBC use block padding. AES-CTR, AES-CFB, AES-OFB, RC4, Rabbit, and AES-GCM do not use the padding setting in the same way. OpenSSL Salted__ output requires an AES-CBC variant and PBKDF2-SHA256, even if another KDF is selected for ordinary envelopes.
Transformation Core:
| Format | What is stored | What must match during decrypt |
|---|---|---|
| Envelope | Version, algorithm, KDF settings, salt, IV or nonce, padding, encoding, ciphertext, creation time, and HMAC when applicable. | The full envelope and the password. AES-GCM associated data is carried when supplied. |
| Raw text | IV or nonce bytes followed by ciphertext bytes, then encoded as Base64 or hex. | Password, salt, algorithm, KDF settings, padding, encoding, and any AES-GCM associated data. |
| Raw binary | The same IV-or-nonce-plus-ciphertext byte layout saved as an octet-stream download. | The binary artifact plus the same separate settings required by raw text. |
| OpenSSL Salted__ | The eight-byte Salted__ marker, an eight-byte salt, and AES-CBC ciphertext. |
An AES-CBC algorithm, the same password, PBKDF2 iteration count, and compatible padding. |
Formula Core:
The raw artifact places the IV or nonce before the encrypted stream. AES-GCM includes its 16-byte authentication tag inside the encrypted byte count returned by the cipher operation:
Braw is the byte count before Base64 or hex encoding, Biv is the IV or nonce length, and Bencrypted is ciphertext plus any included authentication tag. RC4 has no IV segment, so its raw IV contribution is zero.
OpenSSL-style output has a fixed marker and salt before the AES-CBC ciphertext:
If 31 plaintext bytes are encrypted with AES-GCM and a 12-byte nonce, the encrypted stream is 47 bytes because the 16-byte tag is included. The raw byte count is therefore 59 bytes before Base64 or hex changes the visible character count.
| Choice | Technical meaning | Boundary to watch |
|---|---|---|
| AES-GCM | Authenticated encryption with a 12-byte nonce profile and optional associated data. | Never reuse a nonce with the same derived key, and keep associated data byte-for-byte identical on decrypt. |
| AES-CBC, CTR, CFB, OFB | AES compatibility modes with 128, 192, or 256-bit key sizes and 16-byte IVs. | CBC needs a matching padding rule and separate integrity protection when tamper detection matters. |
| DES, TripleDES, RC4, Rabbit | Legacy or historical compatibility ciphers. | Use only for recovery or interop. They are not the default path for new protected text. |
| Argon2id | Memory-hard password stretching. The default profile is 3 passes and 64 MB. | Lower memory or pass counts run faster but reduce the cost of offline guessing. |
| PBKDF2-SHA256 | Iteration-based password stretching with a 210,000 iteration default and 10,000 minimum. | Needed for OpenSSL-style compatibility and useful when both sides cannot use Argon2id. |
For non-GCM envelope output, HMAC-SHA256 provides a separate tamper check. A failed HMAC means the ciphertext, algorithm label, salt, IV, derived integrity key, or password no longer agrees with the stored record. Treat that as a hard failure rather than as a cosmetic warning.
Privacy Notes:
The cipher operation runs in the browser after the page assets load. The pasted text, password, and selected encryption settings are not sent to a tool-specific remote processor for encryption or decryption.
- Plaintext shown on screen, copied to the clipboard, saved in downloads, or left in browser history can still leak.
- Browser extensions, shared devices, clipboard managers, synced folders, and screen recordings are outside the protection of the ciphertext.
- Use managed secret storage for credentials that need access control, rotation, shared ownership, audit logs, or compliance evidence.
Worked Examples:
Modern handoff note
A responder encrypts a 31-byte incident note with AES-GCM (256-bit), Argon2id, and Envelope (.stenc). Cipher Details should show 3 passes and 64 MB, a 16-byte salt, a 12-byte IV or nonce, and a 16-byte auth tag. Security Checklist should mark the algorithm as modern, password stretching as strong, integrity as authenticated, and the container as portable.
Raw output that needs manual notes
A developer chooses Raw (IV + ciphertext) with hex output. The artifact is compact, but it does not carry the salt or KDF parameters. Before sharing it, they record Algorithm, KDF, KDF Params, Salt (hex), Padding, Output encoding, and any associated data. Without those values, the raw string may be impossible to decrypt later.
OpenSSL Salted__ recovery
A Base64 Salted__ artifact arrives from an older command-line workflow. The user switches to an AES-CBC variant, enters the shared password, keeps PBKDF2 iterations aligned with the original command, and chooses the expected padding. If another algorithm is selected, the tool reports that OpenSSL format requires AES-CBC before it attempts decryption.
FAQ:
Which settings should I use for new text?
Use AES-GCM (256-bit), Argon2id, and Envelope (.stenc) unless you need a specific legacy format. That path keeps recovery metadata with the ciphertext and uses authenticated encryption.
Why does the same message encrypt differently each time?
Fresh salt and IV or nonce values are generated when those fields are blank during encryption. Different per-run values are expected and help avoid repeated artifacts under the same password.
Why does raw decrypt ask for the salt?
Raw output carries the IV or nonce with the ciphertext but not the salt or full KDF settings. Enter the original Salt hex and keep the remaining settings matched.
Does HMAC replace AES-GCM?
No. AES-GCM already authenticates its encrypted result. HMAC-SHA256 is useful for envelope output with compatibility modes that do not authenticate ciphertext themselves.
Can this replace a password manager?
No. It encrypts or decrypts one text payload. It does not manage accounts, rotation, shared access, recovery policy, audit history, or automatic secret filling.
Glossary:
- KDF
- Key derivation function, the password-stretching step that turns a password and salt into cipher key material.
- AAD
- Additional authenticated data for AES-GCM. It is checked during decrypt but is not encrypted.
- Authentication tag
- The AES-GCM integrity value that lets decrypt reject changed ciphertext or mismatched parameters.
- HMAC
- A keyed hash-based integrity check used here for non-GCM envelope protection.
- Padding
- Extra bytes used by block modes such as CBC so plaintext fits the cipher's block size.
- OpenSSL Salted__
- A legacy-friendly container shape with a fixed marker, salt, and AES-CBC ciphertext.
References:
- NIST SP 800-38D: Recommendation for Galois/Counter Mode (GCM) and GMAC, NIST, November 2007.
- NIST SP 800-38A: Recommendation for Block Cipher Modes of Operation, NIST, December 2001.
- RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications, RFC Editor, September 2021.
- RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1, RFC Editor, January 2017.
- openssl-enc manual page, OpenSSL Project.
- Cryptographic Storage Cheat Sheet, OWASP Cheat Sheet Series.