| Field | Value | Copy |
|---|---|---|
| {{ row.k }} | {{ row.v }} | |
| No details available. | ||
Text encryption turns readable writing into ciphertext that only the right key can reverse. The practical stakes are simple: a copied note, credential fragment, or draft message can move through more places than intended, so protecting the text before it leaves your hands reduces the chance that plain words travel farther than they should. This package gives you a browser-side way to encrypt or decrypt that text with explicit control over the algorithm, key derivation, integrity checks, and packaging format.
The tool is broader than a one-button cipher wrapper. It supports AES-GCM, multiple AES block and stream modes, DES and TripleDES compatibility modes, RC4, Rabbit, Argon2id and PBKDF2-based key derivation, optional HMAC integrity for envelope output, and several output containers including JSON envelope, raw concatenated payloads, and OpenSSL-style salted formats. That makes it suitable for both everyday note protection and interoperability checks when another system expects a specific style of ciphertext.
A realistic example is sending a short project note to a teammate who already knows the passphrase. You can encrypt the note into a self-describing envelope, share the resulting text, and let the recipient decrypt it later with the same password. Another common use is the opposite direction: taking a ciphertext from a pipeline or a legacy tool and testing whether the salt, IV, algorithm, padding, or associated data match what the sender claimed.
The package also exposes the mechanics rather than hiding them. The output pane shows the produced or recovered text, the metrics table breaks out algorithm, KDF, IV, salt, tag length, ciphertext length, and HMAC status, and the size chart shows how much overhead the chosen format added. The JSON tab preserves the run in a structured payload that is easier to archive or compare than a screenshot.
The limit is important. This is still password-based symmetric encryption, not a key-management system, not a secure messaging protocol, and not a substitute for disciplined secret handling. A weak passphrase stays weak no matter how clean the ciphertext looks, and any failed integrity check should be treated as a stop sign rather than a cosmetic warning.
The first decision is the algorithm family. If you want the safest default inside this package, AES-GCM is the strongest starting point because it gives you authenticated encryption and supports associated data. AES-CBC, CTR, CFB, and OFB are useful when you need compatibility with systems that already expect those modes. DES, TripleDES, RC4, and Rabbit are here as compatibility options rather than modern best-practice defaults.
The second decision is key derivation. Argon2id is the better fit when you control both ends and want stronger password hardening, because the tool lets you tune passes and memory use directly. PBKDF2-SHA256 is the better fit when the receiving side already expects PBKDF2 parameters or when compatibility matters more than using the newer KDF. In both cases the salt must travel with the ciphertext if you expect decryption to work later.
Output format changes how much metadata stays attached to the ciphertext. Envelope output is the most forgiving because it keeps algorithm, KDF, salt, IV, encoding, and optional HMAC in one JSON object. Raw and Raw Binary are leaner, but they assume you will preserve the salt and IV separately. OpenSSL Salted__ output is the interoperability route when another tool expects that classic header and AES-CBC semantics.
Decrypt mode should be approached with suspicion when integrity does not line up. AES-GCM can reject tampered ciphertext through its authentication tag. Envelope HMAC can also fail independently. A bad HMAC, a GCM authentication failure, or a decryption failure with the right-looking ciphertext usually means the password, salt, IV, padding, associated data, or algorithm choice does not actually match the original run.
The tab layout helps you decide what to trust. Ciphertext is the payload itself. Result Metrics tells you whether the supporting parameters look coherent. Size Comparison is useful when choosing between envelope readability and raw compactness. JSON is best when you need a structured record of what happened rather than just the resulting string.
The package encrypts UTF-8 text bytes after deriving key material from a password and salt. For Argon2id, the script uses pass count and memory settings to derive the requested number of bytes. For PBKDF2-SHA256, it derives the required byte length from the configured iteration count. If HMAC is enabled or the chosen algorithm family needs both an encryption key and a MAC key, the derived byte stream is split accordingly before the cipher runs.
Initialization requirements depend on the cipher. AES-GCM expects a 12-byte nonce and produces a 16-byte authentication tag. AES-CBC, AES-CTR, AES-CFB, and AES-OFB use 16-byte IVs. DES-CBC and TripleDES-CBC use 8-byte IVs. RC4 ignores the IV field, while Rabbit uses 8 bytes. The package will generate random values when allowed, or validate a supplied IV or nonce length when you enter one manually.
Packaging happens after encryption. Envelope output stores algorithm, KDF, salt, IV, encoding, ciphertext, and optional HMAC in JSON. Raw output emits the IV concatenated with ciphertext and then encodes that result as Base64 or hex. Raw Binary emits the raw bytes directly for download. OpenSSL Salted__ output uses the classic header plus salt and AES-CBC ciphertext in either Base64 or binary form. That distinction matters because some recipients need metadata attached while others assume you already know the surrounding parameters.
The metrics table and size chart are derived from those same byte counts. You can see plaintext length, ciphertext length, IV bytes, salt bytes, authentication-tag length, associated-data length, and whether an HMAC was present or failed verification. That is useful when the ciphertext text itself looks fine but you need to understand why one format is bulkier, why another system rejects the message, or why a decrypted payload fails integrity.
The entire workflow is local to the browser. Text normalization, key derivation, encryption, decryption, HMAC verification, and export generation all happen client-side in the shipped package. That reduces exposure to a remote helper, but copied ciphertext, saved JSON envelopes, salts, IVs, and downloaded raw binaries are still sensitive artifacts that deserve deliberate handling.
| Component | Package behavior | Why it matters |
|---|---|---|
| AES-GCM | Uses a 12-byte nonce, supports optional associated data, and appends a 16-byte tag | Provides built-in integrity checks without a separate HMAC |
| AES-CBC / CTR / CFB / OFB | Use 16-byte IVs, with padding controls applying to block modes | Supports compatibility with systems that do not use GCM |
| Argon2id | Derives key material from password, salt, pass count, and memory setting | Better hardening when you control both ends of the exchange |
| PBKDF2-SHA256 | Derives key material from password, salt, and iteration count | Compatibility path for tools that already expect PBKDF2 parameters |
| Envelope output | Stores algorithm, KDF, salt, IV, encoding, ciphertext, and optional HMAC in JSON | Minimizes decryption guesswork later |
| OpenSSL Salted__ output | Wraps AES-CBC ciphertext with the legacy Salted__ header and salt | Helps when another endpoint expects OpenSSL-style compatibility |
| Surface | What it shows | Exports available |
|---|---|---|
| Ciphertext | The encrypted or decrypted text payload in the chosen output format | Clipboard copy and direct download |
| Result Metrics | Algorithm, KDF, IV, salt, tag length, HMAC status, and byte counts | CSV copy and CSV download |
| Size Comparison | A chart of plaintext, ciphertext, IV, salt, tag, and envelope overhead | PNG, WebP, JPEG, and CSV |
| JSON | A structured record of the run and its derived metadata | Clipboard copy and JSON download |
The success headline only tells you that the package completed the requested operation with the supplied inputs. The more important interpretation sits in the metrics row: algorithm, KDF, salt, IV, tag length, and HMAC state all need to look plausible for the intended use case. If the metadata is wrong, a beautiful ciphertext string is still operationally useless.
Integrity indicators matter more than aesthetics. A bad HMAC or failed authenticated decrypt means the ciphertext should not be trusted, even if it still looks structurally valid. Raw formats deserve extra care because they separate fewer clues from the ciphertext itself, so a missing salt or mismatched IV can look like a bad password when the real problem is parameter drift.
The size chart is practical rather than decorative. It helps explain why one format is convenient for transport while another is easier to preserve for later decryption. If envelope output looks bigger than expected, remember that the extra bytes are often the metadata you would otherwise need to track manually.
A team member needs to send a short note to a colleague who already knows the passphrase. Envelope output keeps the algorithm, KDF, salt, IV, and ciphertext together, so the receiving side can decrypt without reconstructing those parameters from memory.
A ciphertext from another tool claims to be OpenSSL-compatible but refuses to decrypt. Switching the package to OpenSSL Salted__ handling and AES-CBC narrows the problem quickly: either the password is wrong, or the sender used different salt or padding assumptions than expected.
A developer wants compact output for a pipeline but also wants tamper evidence. Running the same plaintext through raw output, envelope output, and AES-GCM makes the tradeoff visible in the size chart and metrics table before the format choice becomes part of a bigger workflow.
It is the strongest default inside this package because it provides authenticated encryption, but compatibility constraints can still require other modes.
Envelope keeps the parameters with the ciphertext. Raw output is leaner, but you must preserve the salt, IV, and other settings yourself.
It means the decrypted package failed an integrity check. Treat the payload as untrusted until the parameters and source are verified.
The shipped workflow runs in the browser. That reduces remote exposure, but copied or downloaded outputs still need careful handling.