AES-GCM round-trip evidence
How to Use AES Encryption and Base64 Payloads Without Confusing Their Security Boundaries
A practical guide to testing password-based AES payloads: understand which parameters must travel with ciphertext, prefer authenticated encryption where compatible, and never mistake Base64 or a short-lived service request for key management.
Open toolStart by separating encryption, encoding, and access control
AES encryption transforms plaintext into ciphertext using a key. Base64 transforms bytes into text characters so they can travel through JSON, forms, or text fields; anyone with the Base64 value can decode it. Authentication and authorization decide who may obtain or use data. These are separate controls, and none is automatically supplied by the others.
This AES page is not browser-local. It posts plaintext and password to server endpoints for the current encryption or decryption request. The service implementation does not persist the payload itself, but server-side processing is still a materially different exposure boundary from an in-browser converter. Use harmless test text for interoperability work and follow your organization’s approved systems for real secrets, private keys, credentials, and sensitive customer data.
Choose AES-GCM when your compatible format supports it
The tool offers AES-GCM and AES-CBC. AES-GCM provides authenticated encryption: a successful decryption also checks the authentication tag, helping detect modification or use of the wrong password or parameters. AES-CBC in this tool uses PKCS5 padding but does not add a separate authentication mechanism, so it should be reserved for an existing compatible format that specifically requires it and is protected appropriately elsewhere.
For new interoperable test payloads, start with the default AES-GCM settings: 256-bit derived key, PBKDF2-HMAC-SHA256 at 210,000 iterations, a fresh random 16-byte salt, 12-byte IV, and 128-bit tag. Do not change values simply to make an output look different. Compatibility requires both sides to agree on every setting, not merely on the word “AES.”
Treat every parameter as part of the decryption contract
A password alone cannot reproduce a payload. The decrypting side needs the algorithm, key length, PBKDF2 function and iteration count, salt, IV, GCM tag length where applicable, and ciphertext. This tool generates random salt and IV values, derives the AES key using PBKDF2-HMAC-SHA256, and packages these details inside a versioned JSON envelope.
The final tool output is Base64 encoding of that JSON envelope. It contains version, algorithm, KDF name, iterations, key length, Base64 salt, Base64 IV, optional tag length, and Base64 ciphertext. Preserve the entire output exactly. Editing, truncating, re-encoding, or extracting only the ciphertext normally makes decryption fail.
Use a controlled round-trip to test compatibility
Encrypt a non-sensitive sample with an unmistakable marker and record the full output. Decrypt it immediately with the same password to confirm the round trip, then have the other intended implementation decrypt the untouched payload. If it fails, compare the payload contract in order: AES mode, key derivation function, iteration count, key length, salt and IV bytes, tag length, UTF-8 text handling, Base64 alphabet and padding, and JSON field names.
Do not use a production password as a compatibility test. Create a separate test password, keep it outside tickets and chat logs, and discard the sample after testing. An encryption result that round-trips in one tool is evidence only for that exact contract; it does not establish that a broader system has safe key storage, rotation, access controls, or incident recovery.
Make key management the real security decision
A strong algorithm cannot compensate for a weak, reused, shared, or exposed password. Decide who creates, stores, rotates, revokes, and recovers keys before encrypting information that matters. Prefer organization-approved key management, secret storage, and client-side or end-to-end designs when the requirement is that a service operator must not receive plaintext or password material.
Copying, downloading, or sharing an encrypted payload can still create operational risk: a recipient needs the right key and parameters, and a lost key can make data unrecoverable. Base64 output, screenshots, clipboard history, browser extensions, and server request paths are all parts of the handling surface. Use this tool for controlled learning and interoperability tests, not as a substitute for an application-specific cryptographic design review.
Frequently asked questions
Is the AES operation performed locally in my browser?
No. The page sends the supplied text and password to the server AES API for the current request. Treat it as server-side processing.
Does Base64 add another layer of encryption?
No. It is a reversible text representation used to transport the JSON payload and its byte fields.
Why can the same password not decrypt a payload in another AES tool?
AES mode, PBKDF2 function and iterations, key length, salt, IV, tag length, encoding, and payload format must all match exactly.