Base64 Encoding Explained: What It Is and When to Use It

The problem Base64 solves

Many systems were designed to carry text, not arbitrary bytes. Email, for example, was built for plain characters, and some bytes have special meanings in protocols, file formats and programming languages. If you try to push an image, a compressed file or even some Unicode text through such a system unchanged, it can be corrupted along the way.

Base64 solves this by rewriting any sequence of bytes using only 64 characters that are safe almost everywhere: the capital letters A–Z, the lowercase letters a–z, the digits 0–9, and the two symbols + and /. The standard version is defined in RFC 4648.

How the encoding works

Computers store data in bytes of 8 bits. Base64 takes the input 3 bytes at a time, which is 24 bits, and splits those 24 bits into four groups of 6 bits. Six bits can hold 64 different values (0–63), and each value maps to one character of the Base64 alphabet.

Take the word Hi!. Its three bytes are 72, 105 and 33, or in binary 01001000 01101001 00100001. Regrouped into sixes, that is 010010 000110 100100 100001, which is 18, 6, 36 and 33. Looking those up in the alphabet gives SGkh.

Why the output is about 33% larger

Every 3 bytes of input become 4 characters of output, so Base64 text is roughly four-thirds the size of the original. A 30 KB image becomes about 40 KB when embedded as Base64. That overhead is the price of safety, and it is why Base64 is best kept for small pieces of data.

What the = signs mean

When the input length is not a multiple of three, the last group is incomplete. The encoder pads it with zero bits and adds one or two = characters to show how many bytes were missing. Hi (two bytes) encodes to SGk=, and H (one byte) encodes to SA==. Some formats drop the padding because the decoder can work it out from the length.

Text, Unicode and UTF-8

Base64 works on bytes, not letters. To encode text, it first has to be turned into bytes using a character encoding. Today that is almost always UTF-8. English letters take one byte each in UTF-8, but “é” takes two bytes and most emoji take four.

This detail trips up a lot of code. The browser function btoa() only accepts characters with codes up to 255, so btoa("👋") throws an error. A correct encoder converts the text to UTF-8 bytes first, which is what our Base64 Encoder does.

URL-safe Base64

The + and / characters have special meanings in URLs and file names. The URL-safe variant, often called Base64URL, replaces them with - and _ and usually omits the padding. You will see it in JSON Web Tokens (JWTs), in some API keys and in URL parameters.

Where you will meet Base64

• Email attachments. MIME encodes attachments as Base64, wrapped at 76 characters per line.
• Data URLs. Small images or fonts can be embedded directly in HTML or CSS as data:image/png;base64,….
• HTTP Basic authentication. The Authorization header carries username:password encoded as Base64.
• JSON Web Tokens. The header and payload of a JWT are Base64URL-encoded JSON.
• Configuration and secrets. Tools such as Kubernetes store secret values as Base64 so binary data fits in YAML.

Base64 is not encryption

This is the most important point in this guide. Base64 hides nothing. There is no key, and anyone can decode a Base64 string in seconds with a tool like our Base64 Decoder. HTTP Basic authentication is only safe over HTTPS for exactly this reason, and a Base64-encoded secret in a configuration file is still a plain secret.

If you need to protect data, use real encryption such as AES, and keep passwords hashed with an algorithm designed for passwords, such as Argon2 or bcrypt.

Quick checklist

• Use Base64 to move bytes through text-only channels, not to shrink or secure them.
• Always convert text to UTF-8 before encoding.
• Use URL-safe Base64 in URLs, file names and tokens.
• If decoding produces garbage characters, the data is probably binary (an image or a file), not text.