Text Encryptor & Decryptor
Encrypt or decrypt small text locally with AES-GCM, Argon2id or PBKDF2, portable recovery metadata, and integrity checks for safer handoffs.{{ artifactDisplay }}
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Check | Status | Meaning | Copy |
|---|---|---|---|
| {{ row.check }} | {{ row.status }} | {{ row.detail }} |
Password-based encryption has two jobs. It must turn readable text into ciphertext, and it must make password guessing expensive enough that a weak or reused password is not tested cheaply. The cipher handles the first job. A password-based key derivation function, or KDF, combines the password with a random salt and repeated work to produce the key.
Modern protection also needs integrity. AES-GCM is an authenticated-encryption mode, so decryption verifies that the ciphertext, nonce, key, and any associated data agree before returning plaintext. Older modes such as AES-CBC can conceal content but do not detect modification by themselves. A separate message authentication code can protect a compatible envelope, but only when the receiving side verifies the same construction.
- Salt makes the derived key different even when the same password is reused. It is stored with the encrypted artifact and does not need to be secret.
- Nonce or initialization vector gives the cipher a fresh starting value. Its required length and reuse rules depend on the algorithm.
- Authentication tag is the integrity result produced by AES-GCM. A failed tag means the plaintext must not be trusted or displayed.
- Recovery metadata records the algorithm, KDF settings, salt, nonce, padding, encoding, and related values needed to rebuild the same operation.
A portable envelope is easier to recover than a bare ciphertext string because it keeps the recipe with the data. The password remains separate. Raw formats require the operator to preserve the salt, algorithm, KDF work factors, padding, and encoding elsewhere; losing any one of those values can make correct ciphertext unrecoverable.
Compatibility is not the same as current security. AES-CBC, TripleDES, DES, RC4, and Rabbit may be needed to recover existing material, but new text should use authenticated encryption. A long unique passphrase, a fresh salt, and a fresh nonce remain essential because no algorithm setting repairs a guessable password or unsafe key handling.
Encryption protects confidentiality only within its threat model. It does not hide text from a compromised browser, device, extension, clipboard, or person who knows the password. Always prove recovery with a harmless copy before deleting plaintext or relying on an encrypted handoff.
How to Use This Tool:
For new material, keep the default AES-GCM and Argon2id choices and use the portable envelope. Change compatibility settings only when another system requires exact parameters.
- Choose Encrypt for plaintext or Decrypt for an existing artifact, then paste the text or load one supported text-like file up to 2 MiB.
- Enter the exact passphrase. Use a long unique value and send it through a different channel from the encrypted artifact.
- Select AES-GCM for new text. Keep Argon2id unless interoperability requires PBKDF2-HMAC-SHA256, and keep the same KDF work factors for decryption.
- Choose the handoff format. The portable envelope carries recovery settings; raw formats require the original salt and selected settings; OpenSSL
Salted__output requires AES-CBC with PBKDF2.Do not select a legacy cipher for new text merely because it produces shorter or familiar output. Compatibility modes are for recovery or a known external requirement. - Run the operation and review Security checklist. For encryption, save the complete artifact and perform a separate decrypt test before discarding the source. For decryption, stop if integrity verification fails or the recovered text is not exactly what you expected.
Interpreting Results:
The text artifact is the complete handoff only when its format includes all required metadata. The cipher details show the actual algorithm, derivation settings, salt, nonce or IV, padding, and byte counts used in the completed run. Check those values rather than assuming the controls still describe an older result; changing an input invalidates the prior result.
| Signal | Meaning | Required response |
|---|---|---|
| Authenticated or Verified | AES-GCM authentication succeeded, or the compatible envelope HMAC verified. | Still confirm that the password, sender, and recovered content are the ones intended. |
| Unauthenticated | The compatibility result has no verified integrity signal. | Do not treat readable plaintext as proof that ciphertext was not altered. |
| Keep separately | The selected format does not carry the full recovery recipe. | Record the algorithm, KDF parameters, salt, IV, padding, and encoding with the artifact. |
| Failed | An integrity check or decryption condition did not match. | Reject the result and verify the password, artifact, associated data, and settings. |
Ciphertext and complete-artifact byte counts are size evidence, not strength scores. Base64, hexadecimal text, envelope metadata, salt, IV, padding, and an authentication tag can make the artifact larger without weakening or strengthening the underlying cipher.
Technical Details:
Password encryption is a staged mechanism. UTF-8 converts plaintext to bytes. A KDF derives a cipher key from the password and salt. The cipher combines that key with a nonce or IV, while authenticated modes also bind associated data and produce an integrity tag. The final container determines which recovery parameters travel with the ciphertext.
Mechanism Core:
| Stage | Encryption path | Decryption requirement |
|---|---|---|
| Prepare bytes | Encode plaintext and optional associated data as UTF-8. | Recovered bytes must form valid UTF-8 text. |
| Derive key | Run Argon2id or PBKDF2-HMAC-SHA256 with the password, salt, and selected work factors. | Password, salt, KDF, and every work factor must match. |
| Apply cipher | Encrypt with the selected key and fresh nonce or IV. AES-GCM appends a 16-byte authentication tag. | Algorithm, key size, nonce or IV, padding, and associated data must match. |
| Protect compatibility envelope | For a non-GCM portable envelope, optional HMAC-SHA256 covers the algorithm name, salt, IV, and ciphertext. | The same derived MAC key must verify before plaintext is accepted. |
| Serialize | Write a portable JSON envelope, raw IV plus ciphertext, raw binary, or OpenSSL Salted__ artifact. |
The input format and text encoding must be recognized or explicitly selected. |
KDF and parameter rules:
| Parameter | Accepted range or size | Result interpretation |
|---|---|---|
| Argon2id passes | 1 to 10 | The default is 3 passes. The checklist calls at least 3 passes with at least 64 MiB a strong profile. |
| Argon2id memory | 16 to 512 MiB | Higher memory raises browser cost and password-guessing cost; recovery must use the original value. |
| PBKDF2 iterations | 10,000 to 5,000,000 | At least 210,000 is labeled compatible; at least 600,000 is labeled strong. The default is 210,000 for the established interoperability profile. |
| Salt | At least 8 bytes; 16 bytes generated by default | At least 16 bytes receives the full-profile result. A new random salt is created when encryption starts with the field blank. |
| AES-GCM nonce | Exactly 12 bytes | A fresh random nonce is created when the field is blank. |
| AES compatibility IV | Exactly 16 bytes | DES, TripleDES, and Rabbit use 8 bytes; RC4 uses no IV. |
The portable envelope records its version, algorithm, KDF and work factors, salt, IV, padding, ciphertext encoding, optional AES-GCM associated data, and ciphertext. Raw text and raw binary prepend the IV to ciphertext but do not carry the salt or the rest of the recovery recipe. Base64 and hexadecimal are only textual encodings of binary data; they add no confidentiality.
OpenSSL Salted__ compatibility is limited to AES-CBC with PBKDF2-HMAC-SHA256. The artifact begins with the ASCII marker Salted__, followed by an 8-byte salt and the ciphertext. The selected key size, iteration count, password, and padding must match during recovery.
Privacy and Security Notes:
Source text, loaded file content, and the password are processed in the current browser tab and are excluded from the share URL. Result files are created locally. Browser-local processing reduces transmission exposure, but it cannot protect secrets from a compromised device, browser extension, clipboard, or page runtime.
- Never reuse an AES-GCM nonce with the same key. Leave the nonce blank during new encryption so a fresh random 12-byte value is generated.
- Keep the password separate from the ciphertext. Losing the password cannot be repaired, and storing both together removes much of the handoff benefit.
- Legacy and unauthenticated modes can return bytes without proving integrity. Prefer AES-GCM for new text and verify a complete round trip before deleting the source.
- This is a small-text utility, not a key vault, recipient-management system, or long-term archival format.
Worked Examples:
New portable handoff
Encrypt a short note with AES-GCM, Argon2id at 3 passes and 64 MiB, and the portable envelope. Blank salt and nonce fields create fresh 16-byte and 12-byte values. The envelope carries those values, the KDF profile, optional associated data, and ciphertext; the passphrase must travel separately. A successful decrypt of a copied envelope confirms recoverability before handoff.
Existing OpenSSL payload
For a Base64 value beginning with the encoded Salted__ marker, choose decrypt, select the correct AES-CBC key size, PBKDF2 iteration count, and padding, then use OpenSSL input or conservative auto detection. A wrong password or mismatched parameter should be treated as failure even if an unauthenticated compatibility path happens to produce readable characters.
References:
- NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC, National Institute of Standards and Technology, November 2007.
- RFC 9106: Argon2 Memory-Hard Function, RFC Editor, September 2021.
- RFC 8018: PKCS #5 Password-Based Cryptography Specification, RFC Editor, January 2017.
- openssl-enc manual, OpenSSL.
- How to encrypt a file with a password using OpenSSL, Simplified Guide.