What Is Base64 Encoding? A Simple Explanation with Examples

Base64 encoding is one of those concepts that shows up everywhere once you start building software, yet it is rarely explained clearly. This guide breaks down what Base64 actually is, how it works under the hood, and where you will run into it in the real world.

The One-Sentence Definition

Base64 is a way to represent binary data using only 64 “safe” text characters (the uppercase letters A–Z, the lowercase letters a–z, the digits 0–9, plus the two symbols + and /), so that binary content can travel safely through systems that only handle plain text.

That is the whole idea. Base64 does not compress data, it does not encrypt it, and it does not change what the data means. It simply re-packages raw bytes into a string of printable characters.

Why Base64 Exists

Computers store everything as bytes, and a byte can hold any of 256 possible values. Many of those values are not printable text. Some are control characters, some are invisible, and some get mangled or stripped when they pass through text-based channels.

Historically, a lot of communication channels were designed to carry text reliably, but not arbitrary bytes:

• Email bodies (the original SMTP/MIME world) were built around 7-bit ASCII text.
• URLs have reserved characters and a limited safe character set.
• JSON and XML are text formats, so embedding raw binary inside them is awkward or invalid.
• HTML and CSS are text documents too.

If you tried to paste a raw image or a compiled file directly into one of these, the bytes could get corrupted. Base64 solves this by converting any binary blob, an image, a font, a PDF, an encryption key, into plain text that survives the trip intact. You can then decode it back to the exact original bytes on the other end.

How Base64 Works

Here is the core mechanic, and it is surprisingly tidy.

Base64 processes the input 3 bytes at a time. Three bytes is 24 bits. Those 24 bits are then split into 4 groups of 6 bits each:

3 bytes  = 24 bits
24 bits  = 4 groups x 6 bits

Why 6 bits per group? Because 6 bits can represent 2^6 = 64 different values (0 through 63), and Base64 has exactly 64 characters in its alphabet. Each 6-bit group becomes an index into that alphabet, and that index maps to a single output character.

The standard Base64 alphabet is:

Index range	Characters
0–25	A–Z
26–51	a–z
52–61	0–9
62	+
63	/

So every 3 bytes of input turn into 4 characters of output. That is why Base64 output is roughly 33% larger than the input: you get 4 output characters for every 3 input bytes (4 / 3 ≈ 1.33).

The = Padding

There is a catch: not every input is a tidy multiple of 3 bytes. Base64 handles the leftovers with padding using the = character.

• If the final chunk has 2 bytes (16 bits), it is padded to produce 3 characters plus one =.
• If the final chunk has 1 byte (8 bits), it is padded to produce 2 characters plus two ==.

The = is not part of the data. It is a signal that says “the input did not divide evenly into 3, so trim the padding when you decode.” A correctly formed standard Base64 string always has a length that is a multiple of 4 once padding is included.

A Worked Example: Encoding “Man”

The word Man is the classic clean example because it is exactly 3 bytes, so it encodes with no padding at all.

Start with the ASCII values of each character:

Character	Decimal	Binary (8 bits)
M	77	01001101
a	97	01100001
n	110	01101110

Concatenate those into one 24-bit string, then re-split into four 6-bit groups:

Bytes:  01001101 01100001 01101110
Regroup:010011 010110 000101 101110
Decimal:  19     22      5      46

Now map each 6-bit value to the alphabet:

6-bit value	Character
19	T
22	W
5	F
46	u

So Man encodes to TWFu. Decoding reverses the process to recover the original three bytes exactly.

A Quick Reference Table

Here are a few short strings and their correct standard Base64 encodings:

Input	Base64 output	Notes
Man	TWFu	3 bytes, no padding
Hi	SGk=	2 bytes, one =
A	QQ==	1 byte, two ==
Hello	SGVsbG8=	5 bytes, one =

Notice how the padding lines up with the byte count: inputs that are not a multiple of 3 bytes pick up one or two = characters.

Common Real-World Uses

You will bump into Base64 constantly. Some of the most common places:

• Data URIs — embedding small images, icons, or fonts directly inside CSS or HTML so they load without a separate request, for example background: url("data:image/png;base64,iVBORw0KGgo...").
• Email attachments (MIME) — binary attachments are Base64-encoded so they can ride inside a text-based email body.
• HTTP Basic Authentication — the Authorization header sends username:password as a Base64 string (more on why that is not secure below).
• JSON Web Tokens (JWT) — the header and payload segments of a JWT are Base64URL-encoded (the URL-safe variant described next).
• Binary inside JSON or XML — when an API needs to include raw bytes (a file, a thumbnail, a signature) in a text-only payload, it Base64-encodes them.

Important: Base64 Is NOT Encryption

This is the single most common misconception, so it deserves a clear warning.

Base64 is not encryption and provides no security whatsoever. It is fully reversible by anyone, with no key, no password, and no secret involved. The encoding scheme is public and standardized, so decoding a Base64 string is trivial.

• Never use Base64 to “hide” passwords, API keys, tokens, or any sensitive data.
• Seeing a long Base64 string does not mean the data is protected.
• HTTP Basic Auth credentials, for instance, are only Base64-encoded, which is exactly why Basic Auth must always be sent over HTTPS.

If you need actual confidentiality, you need encryption (something like AES or TLS), not encoding.

The URL-Safe Variant

Standard Base64 uses + and /, but both of those characters have special meaning in URLs and can be problematic in filenames. To handle this, there is a URL-safe Base64 variant that simply swaps two characters:

Standard	URL-safe
+	-
/	_

URL-safe Base64 (sometimes written as Base64URL) is what JWTs use, and it often omits the = padding as well. Everything else about the algorithm is identical. If you are working with values that live in a URL, you may also want to look at percent-encoding with our URL encoder, which solves a related but different problem.

How to Encode and Decode Quickly

You do not need to do any of this by hand. If you want to convert text or files to and from Base64 in your browser, try our free Base64 encoder/decoder. Paste in a string, get the encoded result instantly, or drop in a Base64 string to decode it back to the original.

Key Takeaways

• Base64 represents binary data using 64 printable characters so it can pass through text-only systems.
• It works by taking 3 bytes (24 bits) and re-splitting them into 4 groups of 6 bits, each mapping to one character.
• Output is about 33% larger than the input, and = padding fills out chunks that are not a multiple of 3 bytes.
• It is encoding, not encryption: anyone can decode it, so never treat it as a way to protect secrets.
• A URL-safe variant swaps + and / for - and _ for use in URLs and filenames.