ToolSec

๐Ÿ” Crypto & Encoding

What Is Base64 Encoding? (And Why It's Not Encryption)

ยท 6 min read ยท Updated June 27, 2026

Base64 is one of those things you see constantly โ€” in data URLs, email attachments, JWTs, API responses โ€” without always knowing what it's doing. The single most important thing to understand is what it is not: it is not encryption. Let's clear it up.

What problem does Base64 solve?

Many systems were designed to handle text, not arbitrary binary data. Email headers, URLs, JSON and XML can choke on raw bytes โ€” control characters, null bytes, or anything outside a safe range can break them. Base64 solves this by representing any binary data using only 64 "safe" printable characters, so it can travel through text-only channels intact.

How it works

Base64 takes three bytes of input (24 bits) and splits them into four groups of six bits. Each 6-bit group (0โ€“63) maps to one character from the Base64 alphabet: Aโ€“Z, aโ€“z, 0โ€“9, plus + and /. Because three input bytes become four output characters, Base64 output is about 33% larger than the original โ€” the price of being text-safe.

When the input length isn't a multiple of three, Base64 pads the end with one or two = characters so the output stays a multiple of four. That's why you often see = at the end of an encoded string.

Base64 is NOT encryption

This bears repeating because it causes real security incidents. Base64 is fully reversible without any key โ€” anyone can decode it in seconds. Encoding a password or API key in Base64 provides exactly zero protection; treat an encoded secret as if it were written in plain text. If you need confidentiality, encrypt the data; if you need integrity, hash it. Base64 only makes bytes printable.

Base64 vs Base64url

The standard alphabet uses + and /, which have special meaning inside URLs. The URL-safe variant โ€” Base64url โ€” replaces them with - and _ and usually drops the = padding. JWTs and many web APIs use Base64url, which is why a token's parts contain - and _ but never + or /.

The UTF-8 gotcha

A frequent bug is encoding non-ASCII text (accents, emoji, CJK characters) with a naive function that only handles single-byte characters. The fix is to encode the text as UTF-8 bytes first, then Base64 those bytes. A good encoder does this for you so "Cafรฉ ๐ŸŽ‰" round-trips correctly.

Where you'll see it

  • Embedding small images or fonts directly in CSS/HTML as data: URLs.
  • Putting binary blobs (certificates, keys, attachments) inside JSON or XML.
  • HTTP Basic Auth, which Base64-encodes user:password (and therefore needs HTTPS to be safe).
  • Encoding the header and payload of a JWT (as Base64url).

Try it

Encode and decode text โ€” with proper UTF-8 handling โ€” using our Base64 converter. To see how the same bytes look in hexadecimal, try the hex โ†” text converter, and to inspect a Base64url-encoded token, use the JWT decoder.

Frequently asked questions

Is Base64 encryption?

No. Base64 is an encoding, not encryption. It's fully reversible without any key, so it provides no security. Never use it to hide passwords or secrets.

Why is Base64 output larger than the input?

Base64 represents every 3 bytes as 4 characters, so the output is roughly 33% larger. That overhead is the cost of making binary data safe to send through text-only channels.

What's the difference between Base64 and Base64url?

Base64url is a URL-safe variant that replaces + and / with - and _ and usually drops = padding. JWTs and many web APIs use it so the encoded data is safe inside URLs.

Try the related tools

Related guides