What Is Base64 Encoding?

You've seen Base64 even if you didn't know its name: a chunk of text made up of letters, digits, +, /, and maybe some trailing = signs, sitting inside a JSON payload, an Authorization header, or a data: URL. Here's what it actually does, how it works, and where it trips people up.

The short definition

Base64, defined in RFC 4648, is a way to represent arbitrary binary data using only 64 printable ASCII characters: A–Z, a–z, 0–9, plus + and /. It exists because a lot of systems — email, JSON, URLs, XML, HTTP headers — were designed to carry text safely, but not raw bytes. Base64 lets you smuggle any binary blob (an image, a file, a cryptographic signature) through a text-only channel without it getting mangled.

How it actually works

Base64 groups input into 3-byte (24-bit) chunks and re-slices each chunk into four 6-bit pieces. Since 6 bits can only represent 64 distinct values, each piece maps directly onto one character in the 64-character alphabet — that's where the name comes from.

Take the string "Man" as the classic example. Its three bytes, in binary:

M       a       n
01001101 01100001 01101110

Re-sliced into four 6-bit groups:

010011 010110 000101 101110
  19     22      5      46

Each 6-bit number (0–63) indexes into the Base64 alphabet, giving T, W, F, u — so "Man" becomes TWFu. Every 3 bytes of input become exactly 4 characters of output, which is why Base64-encoded data is always about 33% larger than the original — there's no compression happening, just a different representation.

Why the padding (=) shows up

That 3-bytes-in, 4-characters-out grouping only works cleanly when the input length is a multiple of 3. When it isn't, the last group is padded with zero bits and the output is padded with one or two = characters to signal how many bytes of the final group were real:

• Input length divisible by 3 → no padding.
• 1 byte left over → output ends in ==.
• 2 bytes left over → output ends in a single =.

The padding isn't decorative — some decoders reject Base64 that's missing it, which is a common source of "this string won't decode" bugs when data has been passed through a system that strips trailing characters.

Standard vs. URL-safe Base64

The standard alphabet's + and / are both characters with special meaning in URLs and filenames (+ means "space" in query strings, / is a path separator), so RFC 4648 also defines a URL-safe variant that substitutes - for + and _ for /, and conventionally drops the = padding entirely since it's reconstructible from the string length. This is the variant used by JWTs — each segment of a JWT is URL-safe Base64, which is exactly why you can drop a token straight into a URL query parameter without it breaking. Our Base64 Encode and Base64 Decode tools both have a URL-safe toggle for this reason.

Base64 is not encryption

This is the single most common misunderstanding: Base64 provides no confidentiality at all. It's a reversible, keyless transformation — anyone can decode it instantly, with no secret required, the same way you'd unzip a file. HTTP Basic Auth famously sends credentials as Base64(username:password), which looks obscured in a network trace but is fully readable the moment someone decodes it — which is exactly why Basic Auth is only considered safe over HTTPS, where TLS (not the Base64 layer) provides the actual encryption. If you need to hide data, encrypt it first and Base64-encode the ciphertext, not the other way around.

Where you'll run into it

• Data URLs — embedding a small image directly in HTML/CSS with data:image/png;base64,iVBORw0KG..., avoiding a separate HTTP request.
• JWTs — the header and payload segments are URL-safe Base64-encoded JSON. Try decoding one with our JWT Decoder.
• Email attachments (MIME) — binary attachments are Base64-encoded so they survive being routed through mail servers designed around 7-bit text.
• Embedding binary in JSON/XML — neither format has a native binary type, so a file, key, or hash is often carried as a Base64 string field.
• HTTP Basic Authentication — the Authorization: Basic ... header, as described above.

Common mistakes worth avoiding

• Treating it as security. Never use Base64 alone to "protect" sensitive data — it's an encoding, not a cipher.
• Using the standard alphabet where URL-safe is needed (query params, filenames, cookie values) and getting broken output once + or / shows up in real data.
• Assuming string length maps to byte count. A Base64 string is ~4/3 the size of the original bytes — don't use its character count as a proxy for the decoded payload's size without doing the math.
• Forgetting encoding is not Unicode-aware by default. btoa() in JavaScript operates on bytes, not UTF-16 code units, so encoding text with non-Latin1 characters directly will throw or corrupt data unless you first run it through TextEncoder (or a helper that does this for you).

Try it yourself

Encode text or binary-safe strings with Base64 Encode, or paste an encoded string into Base64 Decode to see it reversed instantly — both support the URL-safe alphabet and run entirely in your browser, so nothing you paste in ever leaves your machine.