Base64 Explained: What It Is, Why It's 33% Larger, and Base64URL vs Standard

Base64 shows up everywhere — inside JWTs, in data: URLs, in API responses carrying binary data as text — and it looks enough like encryption that people sometimes treat it that way. It isn't. Base64 is a way of writing arbitrary bytes using only letters, digits, and a couple of punctuation marks, so the result can travel safely through systems built for text. Anyone can decode it instantly; there's no key involved at all.

How it actually works

Base64 takes data 3 bytes (24 bits) at a time and re-slices those 24 bits into four 6-bit chunks. Each 6-bit chunk (a number from 0 to 63) maps to one character from a fixed 64-character alphabet: A–Z, a–z, 0–9, plus two more symbols (+ and / in standard Base64) to reach 64. Three input bytes always become exactly four output characters — which is the entire reason Base64 has a size cost, covered next.

Why it's about 33% larger

Three bytes of binary data in 3 bytes of storage becomes four Base64 characters, and four ASCII characters take 4 bytes to store as text — so encoding turns 3 bytes into 4, a 4 ÷ 3 ratio, which works out to exactly 33.3% larger. This isn't compression and was never meant to be; it's a trade of size for the guarantee that the result is plain, safe text. A 300 KB image, once Base64-encoded for embedding in HTML or CSS, becomes roughly 400 KB of text — the Image to Base64 tool's own result screen shows this directly, with the before-and-after size for whatever image you convert.

Padding: the trailing = characters

Because Base64 works in fixed 3-byte groups, input whose length isn't a multiple of 3 needs padding to complete its final 4-character group. A single leftover byte pads with == (for example, encoding just A gives QQ==); two leftover bytes pad with a single = (AB gives QUI=); an input that's an exact multiple of 3 bytes needs no padding at all (ABC gives QUJD, no =). Padding is why Base64 output length is always a multiple of 4, and why some Base64 strings end in one or two equals signs and others end in none — it isn't a sign anything's wrong.

Not encryption, not even close

Decoding Base64 requires no secret, no password, no key of any kind — it's a fixed, entirely public transformation. Paste any Base64 string into the Base64 Encoder & Decoder and it comes straight back out. If data needs to be kept secret, Base64 does nothing to help with that; encoding something sensitive as Base64 before sending it is exactly as exposed as sending it in plain text, just with a layer of obfuscation that any tool undoes instantly.

Standard Base64 vs. Base64URL

The two characters standard Base64 adds beyond letters and digits — + and / — both have special meaning inside a URL (+ can mean a space, / separates path segments), and = padding can also need escaping depending on where it appears. Base64URL is a small variant built to avoid exactly this: it swaps + for - and / for _, and padding is typically dropped rather than kept, since the decoder can infer it from the string's length. The two encode the same underlying bytes; only the alphabet for two characters (plus the padding convention) differs. This is the variant used inside a JWT — see the JWT guide for exactly where and why.

Where it's actually used

• Data URLs — embedding an image, font, or other binary file directly inside HTML, CSS, or JSON as text, rather than linking to a separate file.
• Tokens and identifiers — JWTs encode their header and payload as Base64URL specifically so the token can be handled safely as a plain string wherever text is expected (URLs, HTTP headers, cookies).
• APIs carrying binary data as JSON — since JSON has no native way to represent raw bytes, binary content (a file, a cryptographic signature) is often Base64-encoded into a JSON string field.

A couple of practical gotchas

Decoding fails on stray whitespace, line breaks, or any character outside the Base64 alphabet — copying a Base64 string out of an email or a document sometimes introduces line breaks that need stripping first. And a bare Base64 string with no data:image/...;base64, prefix is ambiguous about what type of file it represents — Base64 to Image assumes PNG when no format is specified, so if the underlying bytes are actually a JPEG or GIF, include the full data URL prefix rather than the bare string to get the right file type back.