What Is Base64 Encoding, and Why Does It Turn Up Everywhere?

Base64 encoding turns any binary data (an image, a file, a chunk of bytes) into a plain text string that uses only 64 safe characters: A-Z, a-z, 0-9, plus + and /. It exists so binary can travel through systems that were built for text, like email bodies, JSON payloads, and URLs, without getting mangled along the way.

You have already seen it even if the name is new. That long iVBORw0KGgo... blob inside a CSS background-image, the middle segment of a JWT, the string after Basic in an HTTP auth header: all Base64.

What is Base64 encoding?

Base64 is a way to represent binary data as text. Computers store images, PDFs, and audio as raw bytes, and a byte can be any value from 0 to 255. Plenty of those values are control characters or symbols that break when you drop them into an email, a URL, or a JSON string.

Base64 solves that by remapping the raw bytes onto a small, boring alphabet that every system treats the same way. Nothing is compressed and nothing is hidden. A Base64 string is just your original data wearing a costume made of 64 printable characters.

The name is literal. “Base64” means a positional system with 64 symbols, the same way “base10” is our normal decimal digits 0-9. Each Base64 character stands for a number from 0 to 63.

How Base64 works: the 3-bytes-to-4-characters trick

Here is the core idea. Three bytes of input become four Base64 characters of output. Always three in, four out.

Three bytes is 24 bits (3 x 8). Base64 slices those 24 bits into four groups of 6 bits each (4 x 6 = 24). Six bits can hold a number from 0 to 63, which is exactly one slot in the 64-character alphabet. So each 6-bit group picks one output character.

Take the word Man. In ASCII that is three bytes: 77, 97, 110. Write them in binary and stitch them together:

M        a        n
01001101 01100001 01101110

Now regroup those 24 bits into four 6-bit chunks:

010011 010110 000101 101110
  19     22      5      46

Look up 19, 22, 5, and 46 in the alphabet and you get TWFu. That is why Man encodes to a Base64 string of TWFu. Four characters out for three bytes in.

The Base64 alphabet and what ’=’ padding means

The alphabet is fixed and ordered: index 0-25 is A-Z, index 26-51 is a-z, index 52-61 is 0-9, index 62 is +, and index 63 is /. That ordering is why A means zero, not the letter A.

The 3-to-4 math only works cleanly when your input divides evenly into groups of three bytes. Real data rarely does. When there is one leftover byte or two, Base64 pads the output with = so the length always lands on a multiple of four.

One leftover byte encodes to two characters plus ==. Two leftover bytes encode to three characters plus a single =. So a Base64 string ending in == had one extra byte, ending in = had two, and no padding means the input was an exact multiple of three. The = is not part of the data. It is a length marker that tells the decoder how many real bytes to reconstruct.

Base64 is encoding, not encryption (a critical distinction)

This is the part people get wrong, sometimes in production. Base64 is encoding, not encryption. It provides zero security. Anyone can decode a Base64 string in one line of code or by pasting it into a free tool.

Encryption needs a key and hides meaning from anyone without that key. Encoding just changes the format so data survives transport. There is no secret in Base64, so cGFzc3dvcmQ= is not a protected password. It decodes to the literal word password instantly.

If you catch yourself Base64-encoding a token or a secret and thinking it is now safe, stop. It is still fully readable. Use real encryption (or hashing for passwords) when you need protection. For a broader picture of how that fits together, see our guide on what hashing actually is, which is a different tool for a different job.

Why data grows about 33% when you Base64 it

Every Base64 string is bigger than the data it came from. The overhead is roughly 33%.

The reason falls straight out of the 3-to-4 rule. You spend four output characters (four bytes of text) to represent every three bytes of input. That is a 4/3 ratio, so output size is about 133% of the original. A 900 KB image becomes roughly 1.2 MB once it is a Base64 string.

That growth is the tradeoff you accept for text-safety. It is why you inline small icons as Base64 data URIs but keep large images as normal files. Padding and line breaks add a few more bytes on top, though the 33% figure is the number to remember.

Where you actually see Base64: data URIs, email, JWTs, basic auth

Base64 shows up anywhere binary meets a text-only channel.

Data URIs. A data:image/png;base64,... URL embeds an image directly in HTML or CSS, no separate file request. Great for tiny assets, wasteful for big ones because of that 33% bloat.

Email attachments (MIME). Email was designed for 7-bit ASCII text. Every attachment you send, a PDF, a photo, a spreadsheet, gets Base64-encoded so it survives mail servers that only trust plain text. This is the original reason Base64 was standardized.

JWTs. A JSON Web Token is three Base64URL segments joined by dots: header, payload, signature. Decode the middle segment and you can read the claims in plain JSON. That readability is by design, and it is also why you never put secrets in a JWT payload. If you work with these often, our note on reading and formatting JSON payloads pairs well with decoding tokens.

HTTP Basic auth. The Authorization: Basic header is just username:password run through Base64. Again, encoding, not security, which is exactly why Basic auth must ride over HTTPS.

Base64 vs Base64URL, the URL-safe variant

Standard Base64 uses + and /, and both cause problems in URLs. A + can be read as a space, and / is a path separator. The = padding also collides with query-string syntax.

Base64URL fixes this with two swaps: + becomes - and / becomes _. Padding is usually dropped entirely. Everything else is identical. This is the variant JWTs use, and it is what you want any time the string lands in a URL, a filename, or a query parameter. If you are wrestling with special characters in links more generally, the difference between this and percent-encoding is worth knowing, and character sets matter too, which is why how ASCII and UTF-8 differ is a useful companion read.

Encode or decode Base64

The fastest way to understand Base64 is to watch it happen. Paste text into our Base64 encoder and decoder, see the encoded string, then decode it straight back. It runs locally in your browser, which is handy when you are checking a JWT payload or another value you would rather not upload.

Meanwhile, if you are cleaning up the JSON that so often sits next to Base64 (inside JWTs, API responses, data URIs), our JSON formatter will pretty-print and validate it in one paste.

FAQ

Is Base64 encryption? No. Base64 is encoding with no key and no secrecy. Anyone can decode it instantly, so never use it to protect passwords, tokens, or any sensitive data.

Why does Base64 make files bigger? Because it uses four text characters to represent every three bytes of input, a 4-to-3 ratio. That adds about 33% to the size, which is the cost of making binary safe to send as text.

What does the ’=’ at the end of a Base64 string mean? It is padding, not data. It pads the output to a multiple of four characters. One = means the input had two leftover bytes, and == means it had one leftover byte.

What is the difference between Base64 and Base64URL? Base64URL is a URL-safe variant that replaces + with - and / with _, and usually drops the = padding. It is the format used in JWTs and anywhere the string goes into a URL or filename.