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

Base64 is a way to represent any binary data - an image, a file, raw bytes - using only plain text characters that are safe to send through systems built for text. It is one of the most common encodings on the web, quietly powering data URIs, email attachments, JWTs, and HTTP Basic auth headers. This guide explains what Base64 actually is, how the 3-bytes-to-4-characters conversion works, why the output is about 33% larger than the input, the most common places you will run into it, and one point worth being clear about: Base64 is not encryption and provides no security at all.

What is Base64?

Base64 is a binary-to-text encoding. Computers store everything - text, images, sound, executables - as bytes, and a byte can hold any of 256 values. Many older or text-only channels, such as email bodies, URLs, or JSON strings, were designed to carry a limited set of printable characters and can corrupt or strip out arbitrary bytes. Base64 solves this by re-expressing raw bytes using just 64 printable ASCII characters that survive transit safely. You can run any text or file through the Base64 Encoder / Decoder to see this conversion happen in both directions.

How Base64 works

The core idea is a regrouping of bits. Base64 takes the input 3 bytes at a time. Three bytes are 24 bits, and 24 splits evenly into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, and each of those 64 values maps to one character in the Base64 alphabet. So every 3 bytes of input become exactly 4 output characters.

The standard alphabet, in order of value 0 to 63, is:

• A to Z for values 0 to 25
• a to z for values 26 to 51
• 0 to 9 for values 52 to 61
• + for value 62 and / for value 63

When the input length is not a multiple of 3, the final group is padded. The = character fills the leftover slots so the output length is always a multiple of 4. One = means the last group encoded a single byte; two == means it encoded two bytes.

Why Base64 is about 33% larger

Because 3 bytes of input always produce 4 characters of output, the encoded data is 4/3 the size of the original - an increase of roughly 33%. Each output character is itself a byte of ASCII text, so 3 bytes in become 4 bytes out. This overhead is the price you pay for text-safety, and it is the main reason you embed small assets in Base64 but generally do not encode large files this way without a good reason.

A short worked example

Take the two-character text "Hi". As bytes, that is 0x48 (H) and 0x69 (i), or in binary 01001000 01101001. Concatenate the bits and regroup into 6-bit chunks: 010010, 000110, 1001 - and because we only have 2 bytes (16 bits), the last chunk is padded to 6 bits as 100100. That gives the values 18, 6, and 36, which map to S, G, and k. We started with 2 bytes (not a multiple of 3), so one = is appended. The result is "SGk=". Decoding "SGk=" with the Base64 Encoder / Decoder returns "Hi" exactly.

Common uses

Base64 shows up wherever binary data needs to ride inside a text-only container:

• Data URIs - embedding a small image or font directly in HTML or CSS, e.g. src="data:image/png;base64,iVBORw0...", so the browser needs no separate request.
• Email attachments - MIME encodes attachments in Base64 so binary files survive mail servers that expect text.
• Binary inside JSON or XML - JSON has no native binary type, so byte data like a file or a cryptographic key is carried as a Base64 string.
• HTTP Basic authentication - the Authorization header sends "username:password" as Base64, e.g. Authorization: Basic dXNlcjpwYXNz.
• JSON Web Tokens (JWTs) - the header and payload sections are Base64URL-encoded JSON, separated by dots.

If you also need to make text safe for a query string or URL path, that is a different job handled by percent-encoding; see the URL Encoder / Decoder.

Base64 is NOT encryption

This is the single most important thing to understand. Base64 is an encoding, not encryption and not compression. It is fully reversible by anyone, with no key and no secret - decoding is a mechanical, public operation. It provides zero confidentiality: a Base64 string is just your original data wearing a thin text costume. Anyone who sees "dXNlcjpwYXNz" can decode it back to "user:pass" in seconds. And because it expands data by about a third rather than shrinking it, it is the opposite of compression. Never use Base64 to protect passwords, tokens, or any sensitive value - reach for real encryption (and HTTPS) for that.

URL-safe Base64

Two characters in the standard alphabet, + and /, have special meanings in URLs and filenames, so they can break when used there. The URL-safe variant of Base64 fixes this by swapping them out:

• + becomes -
• / becomes _

Padding with = is also often omitted in URL contexts because = is reserved in query strings. This URL-safe variant is what JWTs use (commonly called Base64URL), which is why JWT segments contain - and _ but never + or /. The encoding scheme is otherwise identical; only those two characters differ.

When should you use Base64?

Use Base64 when you need to move binary data through a text-only pipe and the roughly 33% size cost is acceptable - small embedded images, inline fonts, byte fields in JSON, or constructing an auth header. Avoid it for large files (the overhead and lost compression add up), and never treat it as a security measure. When you just need to encode or decode a value quickly and check the result, paste it into the Base64 Encoder / Decoder - it handles both standard and URL-safe encoding entirely in your browser, so your data never leaves your machine.