AES Encryption Online runs on Android through any modern browser tab, applying AES-256-GCM with PBKDF2-SHA-256 key derivation entirely on the phone, with no app install and no upload to any server. Open the page in Chrome, Firefox, or Edge, switch to Encrypt, type the plaintext plus a password of at least 12 UTF-8 bytes, and the page produces a self-contained JSON package that can be copied, saved, or sent through any Android sharing app. Decryption uses the same password against the same package; if the password is wrong or the package was edited, AES-GCM's authentication tag causes the operation to fail without leaking any partial plaintext. Every run generates a fresh 16-byte salt and a fresh 12-byte IV, so encrypting the same text twice gives two different packages by design. The plaintext, the password, the derived key, and the decrypted result never leave the current tab; everything is built and consumed inside the Web Crypto API on the device.
Why a Browser Tool Fits the Phone in Your Pocket
Android users who want to encrypt a snippet of text have two practical paths: install a dedicated AES app from the Play Store, or open a browser tab and run a local Web Crypto implementation. The install path asks for storage permissions, accepts background updates, and ties the user to a vendor's key-handling practices. The browser path needs none of that. The page loads once, then the cryptographic work happens inside the page's JavaScript context using Web Crypto, so the device does not need a second binary just to encrypt fifty words of meeting notes. For people who only need AES encryption a few times a week, that trade favors the browser.
Another reason the browser option suits mobile: it follows the user across devices. The same JSON package can be opened in Chrome on Android, in Safari on iOS, in Firefox on a Linux laptop, or in Edge on Windows. As long as the recipient's browser implements the Web Cryptography Level 2 specification and the package itself was generated with the documented AES-256-GCM parameters, the format travels. The JSON field layout is not a universal standard, however, so a third-party tool that does not reproduce the same UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and JSON fields will not be able to decrypt it. That is fine for personal exchanges but worth keeping in mind before promising compatibility with someone else's stack.
| Situation | Browser AES tool | Android native AES app |
|---|---|---|
| Quick one-off encryption on a borrowed phone | No install, leaves no trace beyond the tab | Adds a permanent app icon and permissions |
| Repeated work with very large files | Best for short text snippets, not a managed vault | Better fit, with a built-in file picker and on-device storage |
| Sharing the same format across phone and laptop | Same JSON package works in any modern browser | Often locked to that app's export format |
| Strict enterprise key management | Not designed for vaults, escrow, or audit trails | Some apps integrate with MDM and key stores |
| Network-restricted environments | Loads once, then runs without further internet | Same — once installed, both work offline |
Open the Tool in Your Android Browser
On an Android phone, the workflow starts in the address bar rather than the Play Store. Open Chrome (or any browser that exposes the Web Crypto API) and load the AES Encryption Online page directly. The page renders a single tab with two modes, two text fields, and the password box; nothing else has to load. Adding the page to the home screen from the browser menu gives a one-tap icon that opens the tool in a standalone frame, which is convenient when the same encryption task is performed several times a week.
Mobile keyboards, autocomplete, and clipboard history all interact with the password field in ways that desktop users do not always think about. Gboard's autocomplete may suggest saving the password, which is fine when the suggestion matches a unique passphrase managed by a real password manager; it is less fine when the suggestion is a phone-saved credential that ends up synced to Google's autofill cloud. Verify the password was typed correctly before encrypting — mobile keyboards regularly autocorrect or substitute similar-looking characters, and a single wrong character will produce an authentication failure on the receiving end. Use a password manager with biometric unlock so the passphrase never has to be retyped by hand on a glass screen.
Encrypt a Text Snippet on Android
The encryption run is three short steps once the page is open. The exact actions, in order, are:
- Tap Encrypt at the top of the page so the form is in encryption mode, then enter the plaintext you want to protect in the first text field.
- Enter a unique password of at least 12 UTF-8 bytes in the password field, then run the encryption. The page derives a 256-bit AES key from PBKDF2-SHA-256 at 210,000 iterations and produces a fresh 16-byte salt plus a fresh 12-byte IV for this run.
- Copy the resulting JSON package from the output area. Preserve the package unchanged — every field, every base64url character, every quoted label must remain in place — and send the password to the recipient through a different channel.
Because the salt and IV are regenerated on every run, the output JSON changes even when the same plaintext and password are entered twice. That is expected and intentional, as documented in NIST SP 800-38D: an initialization vector for AES-GCM must be unique for a given key, and random generation is the simplest way to guarantee that property. Removing the duplication is also what protects against an attacker comparing two ciphertexts to confirm they hide the same message.
The plaintext, the password, the derived key, and the final JSON never leave the tab. They are not submitted to Lizely, not placed in cloud history, and not indexed by autocomplete. Sharing happens only when the user explicitly copies the JSON and pastes it into another app — that boundary is the user's choice, and Android's share sheet makes it easy to hand the package to Signal, Gmail, Drive, or any installed target.
Decrypt the JSON Package Back to Plaintext
On the receiving phone, the workflow mirrors the sender's steps with the mode switched.
- Tap Decrypt so the form is in decryption mode.
- Paste the unchanged JSON package into the package field and the matching password into the password field.
- Run the decryption. If the password is correct and the bytes are intact, the plaintext appears in the result field.
If the password is wrong, or if any byte of the package has been changed, AES-GCM's 128-bit authentication tag fails the check and the page reports an authentication error without revealing partial output. This is the core safety property: a tampered or mistyped password does not slowly leak the message. Validation runs first against the JSON labels, the numeric limits, the field syntax, the exact 16-byte salt length, the exact 12-byte IV length, and the minimum ciphertext length, and only then does Web Crypto attempt the authenticated operation. Any failure along that pipeline is reported as a validation error rather than a successful decryption.
Android Habits That Keep the Package Safe
Browser crypto is local, but the device around it is not. Several Android-specific habits reduce the chance that an exchanged package leaks:
- Treat the password and the package as two separate artifacts. Send the JSON by one app — email, Signal, a file share — and the password by another. Reusing the same channel for both is the most common failure mode.
- Clear the clipboard after pasting the JSON or the decrypted result. Android 13 and later auto-clears copied content after a short window, but older releases retain it indefinitely.
- Disable screen recording and screenshot helpers before handling sensitive content. Some Android keyboards and accessibility tools can capture the screen in the background.
- Use a unique high-entropy password from a password manager. PBKDF2 raises the cost of guessing, but no derivation function can rescue a short, reused, or leaked password.
- Close the browser tab and the app that received the result once the exchange is done. The decrypted plaintext lives in the page's DOM until the tab is closed or refreshed.
If the device is shared, borrowed, or unattended for any length of time, these habits matter more than the choice of cipher. AES-256-GCM is a strong primitive, but it cannot protect content from a clipboard manager, a compromised browser extension, or a screen capture taken after decryption.
Inside the JSON Package: Standard Parts, Tool-Specific Layout
The JSON package declares its own format. The version label is fixed at 1; the cipher label says AES-256-GCM; the key-derivation label says PBKDF2-SHA-256; the iteration count is 210,000. The salt, IV, and ciphertext are stored as base64url strings — the URL-safe Base64 alphabet without padding, per RFC 4648 — so the file can be embedded inside another JSON document or sent over protocols that mangle the characters + and /.
Because the encoding is unpadded, the on-disk length of each base64url field is fixed by the number of raw bytes it carries. A worked example: 16 raw salt bytes = 16 × 8 = 128 bits, and in unpadded base64url at 6 bits per character the salt field is exactly ⌈128 / 6⌉ = ⌈21.33⌉ = 22 characters. The 12-byte IV is 12 × 8 = 96 bits, which encodes as ⌈96 / 6⌉ = 16 characters. The ciphertext length grows with the input and includes the 16-byte GCM authentication tag at the end, so a 30-character plaintext produces a 46-byte ciphertext block — 30 bytes of encrypted content plus 16 bytes of tag — which encodes to ⌈368 / 6⌉ = 62 characters. Those three fixed or predictable lengths are useful sanity checks when reviewing a package by hand on a phone.
The cryptographic ingredients follow standardized specifications, but the surrounding JSON field layout is specific to this tool, so other systems can interoperate only if they reproduce the same UTF-8 handling, PBKDF2 parameters, AES-GCM tag placement, base64url encoding, and JSON fields. Editing the package — for instance by inserting conventional padded Base64 where base64url is expected, swapping the salt and IV fields, or normalizing whitespace — will cause validation to fail on the next decrypt attempt. Treat the package as opaque, copy it as text, and keep the password out of band.
For a deeper look, see Base58 Decode on Android Without Installing an App.