Protect & Encrypt · Field note
How to Encrypt Text in Your Browser Safely
A practical workflow for encrypting short text in the browser, testing decryption, and sharing the passphrase the right way.
Before you start
Run the workflow once with a disposable value, then do a decrypt or restore check before you share anything real.
In brief
What it is: In-browser text encryption is most useful when you need a focused, page-side protection step without a heavier managed system.
Why it matters: It can reduce exposure for short secrets and notes, especially when the workflow is clear and the decrypt side is verified.
Watch for: Using it casually without thinking through passphrase sharing, endpoint hygiene, or whether encryption is even the right primitive.
This is a short-message workflow, not a vault. It works when you need to hand over a secret note, snippet, or temporary value without installing anything, and it fails when the passphrase handling is sloppy.
A more reliable version of the workflow is deliberately boring: long non-reused passphrase, decrypt test, and a separate channel for the passphrase.
What the workflow protects against
- A pre-send decryption test catches formatting issues, copy mistakes, and bad passphrases while you still control the context.
- Separating ciphertext from passphrase lowers the chance that one compromised channel reveals everything.
- Short-lived passphrases are better than reused ones. Do not recycle the same passphrase for unrelated messages.
Run it in this order
- Write the exact text you want to protect and remove anything that should not be shared at all.
- Open Encrypt Text, keep AES-GCM (recommended) selected, and create a long passphrase that you do not reuse.
- Encrypt the text and copy the ciphertext carefully without trimming or reformatting it.
- Open Decrypt Text and run a test with the same passphrase before you send anything.
- Send the encrypted text through one channel and the passphrase through a different one.
- Ask the recipient to confirm they can decrypt successfully, then rotate or discard the passphrase when the task is done.
Use the site tools in this order
- Start on the site homepage or use Protect Text if you want a dedicated text-protection screen.
- Use Decrypt Text immediately after encryption as your verification step.
- Use OpenPGP Message instead when you have a verified recipient public key and do not want to share one message passphrase.
- For links instead of plain text, switch to Encrypt Link; for files, switch to Encrypt File.
Recognize the current and legacy text formats
The homepage now creates an Encrypt Online v1 envelope by default. Its value begins with EOE1 and records the AES-256-GCM, PBKDF2-HMAC-SHA-256, salt, IV, and encoding parameters needed by the matching Decrypt Tool. The header is authenticated with the ciphertext, so changing those fields causes decryption to fail instead of returning unchecked text.
Older Encrypt Online output is an unprefixed CryptoJS/OpenSSL-style Base64 value. The Decrypt Tool cannot reliably tell AES-256-CBC from 3DES by looking at that Base64 string, so choose the original method under Legacy compatibility. New EOE1 output is not expected to work in an older CryptoJS-only consumer.
Failure checks before you send it
- Reusing the same passphrase for many different messages.
- Sending the encrypted text and the passphrase in the same email or chat thread.
- Skipping the decryption test and discovering the problem only after the recipient fails.
- Pasting production secrets into any workflow that your policy requires to stay offline or inside your own environment.
Questions that come up during the workflow
What counts as a strong passphrase here?
Use a long, unique passphrase that you do not reuse anywhere else. Length and uniqueness matter more than clever substitutions.
Why test decryption before sending?
Because encryption is only useful if the recipient can recover the original message. Testing catches copy and passphrase mistakes early.
Can browser encryption replace a full secrets manager?
No. It is great for lightweight sharing workflows, but long-term secret storage and team access control usually need a dedicated secrets-management system.
Do this locally (CLI)
printf '%s' 'hello' | openssl enc -aes-256-cbc -a -salt -pbkdf2 -pass pass:'"$PASSPHRASE"
printf '%s' '<BASE64_CIPHERTEXT>' | openssl enc -d -aes-256-cbc -a -pbkdf2 -pass pass:'"$PASSPHRASE"
- This shows a shared-secret workflow, not a managed key system.
- Keep the passphrase out of shell history if the value is real.
- OpenSSL PBKDF2 output is a separate format and is not interchangeable with ciphertext from this site's Encrypt or Decrypt pages.