Encrypt Online
Theme

Protect & Encrypt

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.

Encrypt Online Editorial Team4 min read
Encrypt Online guide cover on a sage background with the headline "Encrypt text in your browser". One open or closed lock has a circular body and the tall 168:227 overall proportions measured from the site brand icon. Closed shackles use the same width ratio throughout the family; the open variant keeps its full arch, raises it and leaves the right leg visibly clear of the body. Its taller silhouette depicts release rather than a truncated hook. Operation/source: closed.

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.

Worth knowing: Plan the passphrase handoff, endpoint hygiene, and recipient workflow alongside the encryption step.

This workflow is designed for short messages such as a secret note, snippet, or temporary value. A unique passphrase and a tested recipient handoff complete the protection step.

Use a long, unique passphrase, run a decrypt test, and send the passphrase through a separate channel.

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.
  • Use a fresh passphrase for each unrelated message and retire it when the handoff is complete.

Run it in this order

  1. Write the exact text you want to protect and remove anything that should not be shared at all.
  2. Open Encrypt Text, keep AES-GCM (recommended) selected, and create a long passphrase dedicated to this message.
  3. Encrypt the text and copy the ciphertext carefully without trimming or reformatting it.
  4. Open Decrypt Text and run a test with the same passphrase before you send anything.
  5. Send the encrypted text through one channel and the passphrase through a different one.
  6. 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 when you have a verified recipient public key and prefer a key-based handoff.
  • 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 passphrase created for this message. 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?

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)

Shell
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 example shows a shared-secret workflow. Managed key systems support longer-term storage and team access control.
  • 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.

Standards and references

Report a correction