Base64 Is Not Encryption: What It Actually Does (and When to Use It)

Base64 is an encoding, not encryption: it re-spells any bytes using 64 safe text characters so binary data can travel through text-only channels — and anyone can reverse it instantly, no key required. Decode or encode anything in the Base64 encoder/decoder — it runs locally, which matters, because the strings people paste into Base64 tools are so often credentials.

The problem Base64 solves

Plenty of infrastructure was built for text: email bodies, JSON documents, URLs, XML, HTTP headers. Raw binary — an image, a key, a compressed blob — contains bytes those channels mangle or forbid. Base64 is the standard bridge: it represents every possible byte sequence using only A–Z a–z 0–9 + / (64 symbols, hence the name), characters that survive every text channel ever built.

That’s the whole job. You meet it as:

• data: URLs — images inlined into CSS/HTML (data:image/png;base64,iVBORw0…)
• Email attachments — MIME encodes binary parts as Base64
• JSON APIs — binary fields (file uploads, keys, ciphertexts) carried as Base64 strings
• HTTP Basic auth — Authorization: Basic dXNlcjpwYXNz is just user:pass encoded (not encrypted!)
• JWTs — all three segments are base64url-encoded

How the encoding works

Each Base64 character carries 6 bits (2⁶ = 64 symbols). Bytes carry 8. The least common multiple is 24: so Base64 processes input in groups of 3 bytes (24 bits), emitting 4 characters per group.

input bytes :  01001101 01100001 01101110      "Man"
regrouped   :  010011 010110 000101 101110
as Base64   :    T      W      F      u    →   "TWFu"

Two consequences fall straight out of the math:

1. Size: output = input × 4/3 — Base64 costs 33% overhead. A 3 MB image becomes a 4 MB string, which is why inlining large images as data: URLs backfires.
2. Padding: when input length isn’t a multiple of 3, the last group has 1 or 2 real bytes and is filled out with =: "Ma" → TWE=, "M" → TQ==. The padding is why Base64 strings so recognizably end in = or ==.

The variants you’ll actually meet

Variant	Alphabet ends with	Padding	Where
Standard (RFC 4648 §4)	+ /	=	MIME, data: URLs, most APIs
URL-safe / base64url (RFC 4648 §5)	- _	usually omitted	JWTs, URL parameters, filenames

The distinction bites in practice: + means space in URL query strings and / is a path separator, so standard Base64 inside a URL corrupts silently. If a decoder rejects a string that contains - or _, it’s base64url — the LazyTools tool has a URL-safe toggle for exactly this. (For encoding text into URLs, that’s a different tool with different rules: the URL encoder/decoder.)

A UTF-8 footnote that saves debugging time: Base64 encodes bytes, so text must first be converted to bytes. JavaScript’s ancient btoa() assumes Latin-1 and throws (or garbles) on emoji and most non-English text; correct implementations encode via UTF-8 first (TextEncoder), which is what our encoder does — round-tripping héllo 🌍 intact.

The JWT case: readable by design

A JSON Web Token looks opaque — eyJhbGciOi... — but its first two segments (header and payload) are just base64url-encoded JSON. Anyone can read them; the JWT decoder shows the claims and expiry instantly, locally, with no key. Only the third segment, the signature, involves a secret — and what it provides is integrity (the token wasn’t modified), not confidentiality (the contents aren’t hidden).

Two rules follow: never put secrets in a JWT payload, and never paste a live token into a server-backed decoder — a JWT is a bearer credential, and whoever holds it is you. Decode locally or decode expired ones.

Encoding vs encryption vs hashing

The three get conflated constantly, and the confusion has a security cost:

	Reversible?	Needs a key?	Purpose	Examples
Encoding	Yes — by anyone	No	Compatibility / transport	Base64, URL-encoding, HTML entities
Encryption	Yes — with the key	Yes	Confidentiality	AES-GCM, TLS
Hashing	No	No	Integrity / fingerprint	SHA-256 (try the hash generator)

“The password is Base64-encoded in the config file” describes a plaintext password with extra steps. “We hash tokens before storing” and “we encrypt at rest” are real protections. If you can paste it into a decoder and read it, it was never protected.

Common Base64 mistakes

1. Using it as secrecy — Basic auth headers, “obfuscated” API keys, encoded config passwords: all readable by anyone who finds them.
2. Standard alphabet in URLs — + and / corrupt; use base64url.
3. btoa() on Unicode — encode UTF-8 bytes, not raw JS strings.
4. Inlining big files as data: URLs — the 33% tax plus lost caching makes large inline images slower, not faster.
5. Pasting live credentials into online tools — a JWT or API key sent to someone’s server for “decoding” has been disclosed. Client-side tools exist for exactly this reason.

Quick summary

Base64 re-spells bytes as 64 safe characters so binary survives text channels: 3 bytes → 4 characters, 33% larger, =-padded, with a -_ URL-safe variant used by JWTs. It is reversible by anyone and provides no secrecy — that’s encryption’s job, and integrity is hashing’s. Encode and decode in the Base64 tool, inspect tokens in the JWT decoder — both run entirely in your browser, because the things people paste into these tools are exactly the things that shouldn’t travel.

Related tools: HTML entities encoder · regex tester · number base converter. The encoding is specified in RFC 4648.