TL;DR: AES encrypts, Base64 only re-encodes, and Caesar/ROT13 are teaching ciphers with no real security. Knowing which is which stops you from calling encoded text "encrypted" or trusting a cipher a spreadsheet can crack. Pair this guide with Base64 Encoder, AI Hidden Characters, Character Counter and Text Difference.
These four tools get lumped together as "text encryption" online, but only one of them actually protects anything. Text Encryption on CharCount runs AES-GCM for real confidentiality, plus Base64, Caesar and ROT13 for the encoding and puzzle use cases people also search for. Mixing them up has real consequences: Base64-encoded API keys committed to a public repo are not protected, they are just harder to read at a glance.
Background: NIST FIPS 197 defines the AES standard, Web Crypto API is what runs it in the browser, RFC 4648 defines Base64, and OWASP's cryptographic storage cheat sheet covers what "encrypted" should actually mean.
AES: the one that actually encrypts
AES (Advanced Encryption Standard) is a symmetric block cipher: the same key locks and unlocks the text, in blocks of 128 bits, with a key of 128, 192 or 256 bits. It was selected by NIST in 2001 after a public competition (the algorithm itself is Rijndael) and is now the default cipher behind HTTPS, disk encryption and password managers.
CharCount's Text Encryption uses AES-GCM, an authenticated mode: it does not just hide the text, it also detects if the ciphertext was tampered with. Without the correct key, the output is indistinguishable from random bytes — there is no shortcut, no frequency analysis, no brute force within a human lifetime for a 256-bit key.
Base64: encoding, not encryption
Base64 converts arbitrary bytes into a 64-character alphabet (A–Z, a–z, 0–9, + and /, padded with =) so binary data survives systems built for text, like email or JSON. It is fully reversible by anyone, with no key at all — decoding is a lookup table, not a secret.
The mistake is calling this "encryption": a Base64 string looks scrambled, but atob() in any browser console reverses it instantly. Use Base64 to embed images in CSS, pass binary data in URLs, or transport text safely through systems that mangle special characters — never to hide anything from a person who can open dev tools.
Caesar and ROT13: ciphers to learn from, not to trust
The Caesar cipher shifts every letter by a fixed amount through the alphabet — the version historically attributed to Julius Caesar (per Suetonius) used a shift of 3. With only 25 possible shifts, it can be brute-forced by hand in minutes, or broken instantly with letter-frequency analysis.
ROT13 is a Caesar cipher fixed at shift 13 — exactly half of the 26-letter alphabet, which makes it its own inverse: applying ROT13 twice returns the original text. That property made it popular on Usenet and old forums to hide spoilers or punchlines from casual readers, not from anyone who wanted to read them. Neither cipher should ever protect anything you actually care about.
Choosing the right one
- Protecting a password, draft or private note → AES (Text Encryption, AES-GCM mode).
- Embedding binary data in text-only systems (URLs, JSON, CSS) → Base64.
- Hiding a spoiler or teaching substitution ciphers → Caesar or ROT13, nothing sensitive.
- Not sure which? If losing the content to a curious reader would be a problem, it needs AES — not the other two.
A workflow that avoids the common mistake
Paste the text into Text Encryption, pick AES-GCM for anything private, and keep the key somewhere separate from the ciphertext — AES cannot be reversed without it, by design. For Base64, decode-check the output before shipping it anywhere, since it is meant to be read by machines, not to disappear.
For search and publishing quality, also check Base64 Encoder and AI Hidden Characters when cleanup overlaps with hidden or misleading content, and Text Difference to confirm a decrypted or decoded result matches what you expect.