Text AES-256 encryption/decryption tool (keep private) | ZeroTools

This tool begins processing when you enter plaintext and a password, then click "Encrypt Text". It is not a real-time process that updates ciphertext while typing.

If either the plaintext or the password is empty, an error is displayed, and encrypting an empty string alone is not supported. It is an explicit user-initiated execution flow after verifying entered inputs.

Upon execution, plaintext and password are converted into UTF-8 byte sequences using TextEncoder. Subsequently, using browser crypto.getRandomValues, a 16-byte Salt and a 12-byte IV are freshly generated for each encryption operation.

Even when re-encrypting identical plaintext with the same password, changing the Salt and IV typically produces different ciphertext from the previous run.

The behavior creates a fresh combination each time rather than reproducing past output.

Output encoding can be selected between Hex and Base64. This is not a setting that alters the underlying cryptographic algorithm, but rather a difference in how generated byte sequences are represented as copyable text.

Hex represents each byte with two characters and becomes longer, whereas Base64 represents identical byte sequences more compactly.

Whichever you select, fixed parameters for key derivation and AES-GCM remain unchanged.

Encoding format selection takes effect upon the next encryption execution. Results already displayed on screen are not re-encoded simply by switching radio buttons.

If results in an alternative format are required, re-select the format and run encryption again. In that case, Salt and IV are also newly generated, so ciphertext itself differs from previous output in addition to textual representation.

The entered password is not used directly as an AES key. The UTF-8 password and 16-byte Salt are passed to Web Crypto PBKDF2, iterating 100,000 times with SHA-256 to derive a 256-bit AES-GCM key.

These algorithms and parameters cannot be changed from the interface and are fixed in current implementation.

Plaintext encryption employs AES-GCM and a 12-byte IV. Because tagLength is not specified in code, the W3C Web Cryptography specification default of 128 bits applies.

The value returned by subtle.encrypt is a byte sequence concatenating ciphertext body C and authentication tag T. The "Ciphertext" field on screen displays this tag-inclusive value, with no option to isolate the tag into a separate field.

Additional Authenticated Data (AAD) is not specified.

AES-GCM is an authenticated cipher combining confidentiality and tamper detection. However, having a "256-bit AES key" is distinct from an entered password possessing 256-bit equivalent guessing difficulty.

A third party obtaining ciphertext and Salt can attempt offline guessing by iteratively deriving keys and decrypting with candidate passwords.

While PBKDF2 iterations increase per-guess computation, they do not automatically strengthen short words or reused passwords.

NIST SP 800-132 addresses deriving data-at-rest keys from passwords, salts, and iteration counts, but it was published in 2010 with planned revisions.

The fixed 100,000 iterations in this tool cannot be asserted as universally sufficient across all hardware, data types, or future dates.

Users should choose long, unique, hard-to-guess passphrases and avoid treating AES key length alone as proof of safety.

The results section displays Salt, IV, and tag-inclusive ciphertext individually, alongside combined encrypted text joining these three components with half-width colons.

The structure is ordered from left to right as Salt, IV, and ciphertext. The password is not included. When copying values required for decryption together, use the combined field and manage the password separately.

As a concrete example, if plaintext converted to UTF-8 is 12 bytes, adding a 128-bit (16-byte) authentication tag results in a 28-byte ciphertext entity.

In Hex output, 16-byte Salt produces 32 characters, 12-byte IV produces 24 characters, and tag-inclusive ciphertext produces 56 characters.

Including two colons, combined text length is 32 + 1 + 24 + 1 + 56 = 114 characters. Japanese "秘密メモ" is 12 bytes in UTF-8, serving as an input example for this length calculation.

Selecting Base64 for the same 12-byte plaintext example yields 24 characters for Salt, 16 characters for IV, and 40 characters for tag-inclusive ciphertext, totaling 82 characters with colons.

Trailing equal signs are part of Base64 data; do not strip them when pasting into emails or forms. Converting to Hex or Base64 aims to prevent character corruption; encoding itself does not add cryptographic strength.

The combined format is not self-describing. Because parameters such as PBKDF2, SHA-256, 100,000 iterations, AES-GCM, tag length, UTF-8, and tool version numbers are not stored within the string, fixed parameters cannot be determined from text alone.

For data needing decryption in the future, record applied algorithms and conditions separately, and maintain original data and recovery procedures.

Even if site implementations change later, continuous decryption of legacy formats is not guaranteed.

Decryption requires the password used during encryption, along with correct Salt, IV, and tag-inclusive ciphertext. Input methods consist of pasting combined encrypted text or entering the three elements into individual fields.

For combined input, failing to split into exactly three colon-delimited components yields a format error. In individual input, users select Hex or Base64.

Combined input format detection attempts Hex decoding if all three components consist solely of characters 0-9, a-f, and A-F, falling back to Base64 otherwise.

This detection is a simple heuristic inspecting character sequences rather than reading an embedded format identifier. Standard Base64 representations of 16-byte Salt generated by this tool contain trailing equal signs, distinguishing normal outputs from Hex-only strings.

Decryption derives keys under identical PBKDF2 conditions and passes entered IV and ciphertext to subtle.decrypt. If passwords differ, Salt or IV differ, ciphertext or authentication tags are truncated, or values changed during storage, authentication fails and decryption aborts.

While AES-GCM authentication tags detect tampering, this does not constitute an assertion that accidental acceptance is mathematically impossible under all data configurations.

This screen groups decryption exceptions without fine-grained categorization, displaying "Decryption failed. The password may be incorrect or the data is corrupted." Consequently, one cannot determine from display alone whether the issue stems from incorrect password, mismatched Salt/IV, improper encoding selection, or truncated ciphertext.

Upon failure, first verify whether combined text has exactly two colons without stray surrounding characters and whether individual format selections match, then check saved values and passwords.

Decryption results are converted back to text via TextDecoder. Because data generated by this tool assumes UTF-8 plaintext, feeding values produced by external software encrypting binary data or alternative encodings under identical cryptographic conditions does not guarantee expected text output.

Compatibility with other products requires alignment not just in algorithm names, but in Salt, iteration count, tag positioning, and character encoding.

Entered plaintext, passwords, generated Salt, IV, ciphertext, and decrypted plaintext reside in current React state and the DOM. Routines for storing history in LocalStorage or IndexedDB, automatic file saving, or registering credentials with password managers are not present.

Reloading the page reinitializes screen state, but routines explicitly zeroing memory used by JavaScript strings do not exist, offering no guarantee of wiping traces in physical RAM.

The encryption component contains no routines transmitting inputs to servers for encryption or decryption purposes. However, this does not mean the overall webpage is devoid of network traffic.

Communications distinct from encryption functions may occur, including asset downloads for page rendering, analytics, and advertisements.

Distinguish between implementations lacking routines to send cryptographic inputs and pages having zero communications.

The copy button awaits resolution of Clipboard API writes, switching to a checkmark display only upon success. If writing fails due to permissions or environment constraints, an error is displayed.

Reverting after 2 seconds merely alters button appearance and does not clear clipboard contents. Possibilities that operating systems or clipboard history utilities retain plaintext, non-password outputs, or decrypted results cannot be controlled from this page.

The interface provides no save button or automatic backups for encryption results. Users must copy and store necessary combined encrypted text manually.

Rather than relying solely on copy confirmation indicators, check after pasting into storage whether leading/trailing characters or colons are intact.

For critical data, verify that stored ciphertext successfully decrypts via separate procedures before deleting original plaintext.

Choose passwords that are long, unique, and hard to guess. Reusing passwords across other services allows unrelated breaches to affect offline guessing against this ciphertext.

While Salt and IV are generally not secrets like passwords, they are indispensable for correct decryption. Manage roles separately so neither passwords nor combined strings and component sets are lost.

When transmitting ciphertext and password to a counterparty, placing both in the same message allows anyone with access to that message to decrypt it.

Delivery channels and identity verification remain outside the scope of this tool. Determine transmission methods, storage access controls, backups, and deletion timelines according to your requirements.

Password resets, recovery keys, or administrator recovery are not implemented.

This interface is designed for pasted text and does not support file selection, folder processing, key distribution, collaborative editing, version control, or expiring shares.

While input character limits are not displayed on screen, processing duration and memory usage depend on browsers and hardware, providing no assurance for large-scale data handling capacity.

When working with files, choose dedicated file encryption tools and recovery testing.

Encrypting with AES-GCM cannot prevent keyloggers capturing text before input, malware reading screens after decryption, shoulder surfing, phishing, weak device authentication, or accidental sharing with wrong recipients.

Algorithm designations alone do not protect your entire operational environment. Choose tools tailored to specific purposes: a password generator for candidate passphrases, a file encryptor for files, or a hash calculator to verify data integrity without reversibility.