Base64 Encoding Explained: How It Works, Where It Is Used and Common Myths

Why Base64 exists

All computer data is ultimately bytes. Yet many channels can only carry text safely: email bodies, HTTP headers, JSON documents and URLs. If you push raw image bytes or ciphertext through those channels, control characters and line breaks can corrupt the data, or an intermediate system may rewrite it.

Base64 solves this by mapping any sequence of bytes onto a 64-character alphabet made of upper- and lower-case letters, digits, plus + and /. Those characters are treated as safe almost everywhere, so binary data can travel through text-only channels intact. The format is standardised in RFC 4648.

Three bytes become four characters

The core idea is simple. Input is taken three bytes (24 bits) at a time, and those 24 bits are split into four groups of six bits. Six bits can represent 64 values, from 0 to 63, so each group maps to one character: 0–25 are A–Z, 26–51 are a–z, 52–61 are 0–9, 62 is + and 63 is /.

Take the word Man. Its bytes are 77, 97 and 110. Splitting those 24 bits into six-bit groups gives 19, 22, 5 and 46, which map to TWFu. Non-English text works the same way once it is turned into bytes: the Korean character 한 is three bytes in UTF-8 (ED 95 9C) and therefore becomes exactly four characters, 7ZWc.

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

Because three bytes always become four characters, Base64 output is about 33% larger than the input. A 1,000-byte file becomes 1,336 characters. That is why embedding large images as data URIs makes a page noticeably heavier.

What the trailing = means

When the input length is not a multiple of three, the last group has only one or two bytes. The missing bits are filled with zeros and one or two = characters are added so the output length stays a multiple of four. One leftover byte produces ==, two leftover bytes produce a single =. That is why Hi (two bytes) becomes SGk=.

Padding is only a hint that helps the decoder restore the exact length; it carries no data. Some systems omit it, and strict decoders may then reject the string with an invalid length error. Adding = characters until the length is a multiple of four usually fixes it.

Base64URL for links and file names

The + and / characters have special meanings in URLs: + may be read as a space and / separates path segments. The Base64URL variant therefore replaces + with - and / with _. The same two bytes FB FF encode to +/8= in standard Base64 and to -_8= in Base64URL.

All three parts of a JSON Web Token are Base64URL-encoded, usually without padding. Decoding the middle part of a JWT reveals claims such as the user ID and expiry time in plain text, which leads directly to the most important point about Base64.

The big myth: Base64 is not encryption

Base64 output looks random, so it is often mistaken for encryption. But there is no key: anyone can reverse it instantly using the same public rules. Storing or sending passwords or API keys as Base64 gives no more protection than plain text.

HTTP Basic authentication is a good example. The user name and password are joined with a colon and Base64-encoded, but that is merely a transport format; the real protection comes from HTTPS. If you need to hide data, use encryption such as AES. If you need to detect tampering, use a hash or a signature.

Where you will meet Base64 in practice

Recognising where Base64 is used helps you identify unfamiliar strings quickly.

• Email attachments: MIME encodes binary attachments as Base64 inside the message body.
• Data URIs: small icons can be embedded as data:image/png;base64,... in CSS or HTML. Keep this to images of a few kilobytes.
• JWT and OAuth: token headers and payloads use Base64URL.
• API payloads: JSON cannot hold raw bytes, so files and signatures are sent as Base64 strings.
• Certificates and keys: the body of a PEM file that starts with -----BEGIN CERTIFICATE----- is Base64.

Troubleshooting a string that will not decode

Most decoding errors have a handful of causes. First, check for line breaks or spaces; email and PEM files often wrap every 76 characters. Second, if you see - or _, the string is Base64URL and must be decoded as such. Third, if the length is not a multiple of four, the padding is missing.

If decoding succeeds but the text looks garbled, the original character encoding is the problem. Korean, for example, produces completely different bytes in UTF-8 and EUC-KR, so you must interpret the result with the same character set that was used for encoding. The AIBIZAP Base64 tool uses UTF-8, so Korean, Japanese and emoji round-trip correctly.