What Is Base64 Encoding? (And When to Use It)

Base64 is a way to represent arbitrary binary data — images, files, or raw bytes — as a string of ordinary printable characters. It converts any sequence of bytes into an alphabet of 64 safe ASCII characters so that the data can travel through systems that only understand text, such as email, JSON APIs, and HTTP headers, without being garbled along the way.

The core problem Base64 solves

Computers store everything as binary: sequences of bytes, each a number from 0 to 255. Many communication protocols, however, were designed for text. Old email systems, for instance, expected 7-bit ASCII characters (values 0–127) and would silently corrupt or drop bytes outside that range. HTTP headers must contain only printable US-ASCII. JSON has no native binary type at all.

When you need to carry binary data through one of these text-only channels, you need a way to represent every possible byte value using only a safe subset of characters. Base64 is the most widely adopted solution to that problem.

The name reflects the math: the encoding uses exactly 64 distinct characters — the 26 uppercase letters A–Z, the 26 lowercase letters a–z, the digits 0–9, and two additional characters, typically + and / (or - and _ in the URL-safe variant). Because 2⁶ = 64, each character carries exactly 6 bits of information, which is how the algorithm maps bytes to characters.

How Base64 encoding works

The algorithm processes input 3 bytes at a time. Three bytes is 24 bits, which divides cleanly into four 6-bit groups. Each 6-bit group is used as an index into the 64-character alphabet to produce one output character. So every 3 bytes of input becomes exactly 4 characters of output.

A concrete example

Take the three-character ASCII string Man. In binary, that is:

You can verify this yourself: encode Man in any Base64 tool and you will always get TWFu. The mapping is deterministic and reversible — the decoder reads each character's position in the alphabet, recovers the 6-bit values, reassembles the bits into bytes, and produces the original input.

Padding with =

When the input length is not a multiple of three, the encoder cannot fill the last group of four characters completely. It pads the output with one or two = signs to bring it to a full group of four. The padding tells the decoder how many meaningful bytes are in the last group, ensuring clean round-trips even for inputs of any length.

How much larger does Base64 make the data?

Because 3 input bytes produce 4 output characters, Base64 increases the size of the data by about one third. More precisely, the encoded output is always ceil(n / 3) × 4 characters long, where n is the number of input bytes. A 100-byte image becomes roughly 136 characters of Base64 text. A 1 MB file becomes about 1.37 MB of Base64. That size overhead is the main reason to avoid Base64 when a binary-safe channel is available.

Common real-world uses of Base64

Base64 appears in more places than most developers initially realize:

• Email attachments (MIME). When your email client sends a PDF, it Base64-encodes the binary file and embeds the text into the message body. The receiving client decodes it back before saving the attachment.
• Embedding images in CSS and HTML. A small icon can be inlined directly in a stylesheet as a data URI: background-image: url("data:image/png;base64,iVBORw0K..."). This saves an HTTP round-trip for tiny assets.
• HTTP Basic Authentication. The Authorization: Basic header carries credentials as Base64 of username:password. Note: this is not encryption — the credentials are trivially recoverable. Always use HTTPS alongside it.
• JSON Web Tokens (JWTs). A JWT is three Base64url-encoded segments joined by dots: header, payload, and signature. The URL-safe variant (- instead of +, _ instead of /, no padding) ensures the token can be used in URLs and cookies without escaping.
• Binary data in JSON APIs. When an API needs to return or accept an image, audio clip, or file in a JSON response, Base64 is the standard way to represent those bytes as a string value inside the JSON object.
• Cryptographic keys and certificates. PEM-format certificates (the -----BEGIN CERTIFICATE----- blocks you copy from servers) contain the DER-encoded certificate wrapped in Base64 so it can be safely pasted into text files and config.

Base64 is not encryption

This is the single most important thing to understand about Base64: it provides zero security. Anyone who sees a Base64 string can decode it instantly. It is a data-representation format, not a confidentiality mechanism.

A common mistake is to Base64-encode a secret and assume it is "hidden" or "obfuscated." It is not. The string SGVsbG8gV29ybGQ= decodes to Hello World in under a second using any decoder. If you need to protect data in transit, use TLS. If you need to protect data at rest, use a proper encryption algorithm such as AES-256. Base64 is for safe transport, not for secrecy.

Base64 vs. URL encoding — when to use which

These two encodings solve related but different problems, and they are not interchangeable:

Use Base64 when you need to embed binary data inside a text container. Use URL encoding (percent-encoding) when you need to pass a string through a URL query parameter. If you need Base64 inside a URL, use the URL-safe Base64 variant (- and _ instead of + and /, no = padding) to avoid conflicts with URL syntax.

Decoding Base64 — checking what a string actually contains

Developers often encounter Base64 strings in logs, API responses, or authentication headers and need to inspect their contents quickly. The algorithm is deterministic, so decoding is equally straightforward: each group of four characters maps back to three bytes. A few things worth knowing when decoding:

• If the string ends in one =, the last group encodes 2 bytes. Two = signs means the last group is 1 byte.
• Standard Base64 uses + and /. URL-safe Base64 uses - and _. If you try to decode a URL-safe string with a standard decoder without substituting those characters first, the result will be wrong. Figro's tool handles both variants automatically.
• Base64 of binary data (like an image or compiled file) will not produce readable text — it will look like garbled bytes. That is expected; the original data was not text.

When not to use Base64

Base64 is not always the right tool. Avoid it in these situations:

• When a binary-safe channel exists. HTTP request and response bodies can carry raw binary data perfectly well. If your API client and server both support multipart or binary payloads, use those instead of Base64-encoding files — you will save the ~33% size penalty and the CPU overhead of encoding and decoding.
• For storing large binary data in databases. Databases with native binary column types (BYTEA in PostgreSQL, BLOB in MySQL/SQLite) store raw bytes more efficiently and do not need the Base64 layer.
• As a substitute for encryption or hashing. Reiterated here because it is a recurring mistake: Base64 is not a security mechanism. If the data is sensitive, encrypt it or hash it with an appropriate algorithm. Base64 alone is reversible by anyone.

Figro's guides are educational and independent. They are not professional advice. Some pages include affiliate links; if you purchase through them we may earn a commission at no extra cost to you.