Base64 is not encryption: choose encoding, encryption or hashing

If you find cGFzc3dvcmQxMjM= in a configuration file, decoding it gives password123. No key is required. Base64 is useful for representing bytes as text, but it does not protect a password from someone who can read the file.

Choose the operation by the job: encoding for representation, encryption for confidentiality, and hashing for a fingerprint you can compare.

Base64 changes the representation

Standard Base64 uses letters, digits, + and /, with = for padding. It is used where binary data needs a text representation, including attachments and data embedded in text formats.

Every three input bytes become four Base64 characters. Short inputs need padding, so the increase is not always exactly one third:

Plain text, encoded as UTF-8	Base64
f	Zg==
fo	Zm8=
foo	Zm9v
password123	cGFzc3dvcmQxMjM=

The Base64 tool encodes text as UTF-8 before conversion, so accented characters and emoji are represented by their bytes rather than assumed to be single-byte characters.

Its decoder turns the decoded bytes back into UTF-8 text. If the original data is an image or another binary file, the result may look garbled or contain replacement characters. That is not evidence of encryption; a text decoder is simply the wrong viewer for those bytes.

Base64url is a related alphabet

Base64url replaces + and / with - and _. Protocols such as JWT also omit the trailing padding. The local decoder accepts both alphabets and restores missing padding where possible.

The two variants are defined in RFC 4648. Use the variant required by the receiving system rather than assuming standard Base64 can be pasted unaltered into every URL.

Percent-encoding and HTML character references also change how text is represented. They can make a value fit a particular syntax; they do not make the value confidential.

Encryption needs keys and a secure design

Encryption is designed to let an authorised recipient recover the original data while keeping it unreadable to someone without the needed key. Established algorithms can be public; the key is what must be protected.

The security depends on how the algorithm is used, key quality and key handling. Authenticated encryption also checks whether the protected data has been altered. Merely labelling an operation “AES” is not enough to describe a complete secure system.

An encrypted value may itself be written in Base64 for storage or transport. Decoding that outer Base64 layer reveals ciphertext bytes, not necessarily the original message. Appearance alone cannot tell you which operations were applied.

Hashes let you compare inputs, not recover them

SHA-256 produces a 32-byte digest, usually displayed as 64 hexadecimal characters. The same input bytes produce the same digest. A changed input is overwhelmingly likely to produce a different one.

There is no general decryption operation for a hash. But that does not mean a hashed value cannot be discovered: someone can hash likely guesses and compare the results. A common password, short PIN or small list of possible identifiers is vulnerable to that approach.

Different inputs can also share a hash, because a fixed-size output cannot uniquely represent unlimited inputs. A modern cryptographic hash is designed to make finding such collisions impractical, not impossible as a matter of mathematics.

The hash generator offers text digests including SHA-256, SHA-384 and SHA-512. It also exposes legacy MD5 and SHA-1 and the non-cryptographic CRC32 checksum. These are not password-storage tools.

Password storage needs more than a fast hash

A password-storage function combines a unique salt with deliberately expensive computation to make guessing more costly. The salt prevents one precomputed result from being reused across accounts; it is not a secret key and does not stop guesses against a single account.

OWASP’s password-storage guidance recommends purpose-built functions such as Argon2id. Use a maintained password-handling library rather than designing a scheme by repeatedly calling a general hash function.

A signed JWT illustrates the distinction

In a three-part signed JWT, the header and claims are Base64url-encoded JSON. The JWT decoder can read those sections without a signing key. The third section is a signature or message authentication code, depending on the algorithm.

A verifier must actually check that protection and the required claims before trusting the token. Decoding alone proves nothing about its authenticity. JWTs can also be encrypted using a different format, so “every JWT is readable” is too broad.

For any unfamiliar string, find the format or the code that produced it. That is more informative than deciding it must be secure because it looks unreadable.

Last reviewed 2 October 2026.