What Is Base64 Encoding (and Why It Makes Files Bigger)

October 17, 2026 • NOFYI Editorial Team

You may have seen a long string of letters, numbers, plus signs, and slashes in a web page, an email, or a configuration file and wondered what it was. Often, it is Base64. Base64 looks like scrambled text, but it is not encryption and it is not compression. It is a way of representing binary data using only printable text characters. This guide explains what Base64 is, why it makes files bigger, where it is used, and what it should never be used for.

Base64 is useful because some systems were designed to handle text safely, not raw binary data. Email, web addresses, JSON files, HTML, and CSS can all have trouble with bytes that represent images, files, or control characters. Base64 converts those bytes into a safe alphabet that can travel through text-based systems without being changed or broken. The trade-off is size. Base64 output is always larger than the original data.

The 64-Character Alphabet

Base64 uses 64 characters to represent data. The standard alphabet is uppercase A to Z, lowercase a to z, digits 0 to 9, plus plus, and slash. That is 26 plus 26 plus 10 plus 2, which equals 64. Padding with equals signs is added at the end when needed, to make the output length a multiple of four characters.

The reason for 64 is simple. Six bits can represent 64 different values, from 0 to 63. Base64 takes the input bytes, splits them into groups of six bits, and maps each six-bit group to one character in the alphabet. Three bytes of input contain 24 bits, which divide neatly into four groups of six bits. So three input bytes become four Base64 characters. That 3-to-4 relationship is the key to understanding why Base64 grows.

There are variants. URL-safe Base64 replaces plus with hyphen and slash with underscore, because plus and slash have special meanings in web addresses. Some systems omit padding. The core idea stays the same: binary data is rewritten using a limited, text-safe alphabet.

Base64 Is Encoding, Not Encryption

Encoding changes the representation of data. Encryption changes who can read it. Base64 is encoding. Anyone who recognizes a Base64 string can decode it in seconds with a free tool. There is no key, no password, and no secret step. If you can encode it, anyone else can decode it.

This distinction matters for security. Encoding a password, an API key, or a private message in Base64 does not hide it. It only makes it look unreadable at a glance. A person who copies the string into a decoder will see the original immediately. Never treat Base64 as protection. For real protection, use encryption designed for that purpose, access controls, and secure storage.

A common misunderstanding comes from seeing Base64 in authentication headers. Basic authentication, for example, sends a username and password joined by a colon and encoded in Base64. That is not secure on its own. It is only safe when used over an encrypted connection such as HTTPS, where the whole request is protected. The Base64 step exists to make the credentials safe to transmit as text, not to hide them.

Why Base64 Makes Files Bigger: About 33 Percent

Because three bytes become four characters, Base64 output is four-thirds the size of the input. Four divided by three is about 1.333, so the encoded data is about 33 percent larger. Padding adds a tiny amount more in some cases, but the main growth comes from the 3-to-4 conversion.

For small strings, the extra size barely matters. For large files, it matters a lot. A 3 MB image becomes about 4 MB when encoded in Base64. A 30 MB file becomes about 40 MB. If you store many encoded files, the extra space adds up. If you send encoded files over a network, the transfer takes longer. That is why Base64 is best for small pieces of data, not for large files.

There is another cost. Encoding and decoding take time and memory. For a small image or a short token, that cost is negligible. For a large video or archive, it can be noticeable. If a system must handle large binary data, it is usually better to send the binary file directly or use a link, rather than embedding a Base64 version.

Where Base64 Is Used

Base64 appears in many everyday places. Data URIs in HTML and CSS embed small images directly in a web page using a string like data:image/png;base64, followed by the encoded image. This can reduce the number of separate requests a browser must make, which can help for tiny icons or logos. For large images, it usually hurts performance because the page becomes larger and cannot cache the image separately.

Email systems use Base64 to send attachments through text-based mail protocols. Many APIs return small binary values, such as image thumbnails or encrypted tokens, as Base64 strings inside JSON, because JSON is a text format and cannot safely hold raw bytes. Configuration files, QR-code payloads, and some database fields also use Base64 for the same reason: the data must survive as text.

Base64 is also useful in examples, tests, and debugging. A short encoded string can be pasted into a message, a ticket, or a document without worrying that special bytes will be lost. It is a convenient way to share a small binary sample in a text-only channel.

How Encoding Works, Step by Step

Encoding works by regrouping bits. Imagine the input as a stream of bits. The encoder takes the first 24 bits, splits them into four groups of six bits, and looks up each group in the 64-character alphabet. It repeats this process for the rest of the input. If the final group has fewer than three bytes, the encoder adds padding so the output length stays a multiple of four.

Decoding reverses the process. The decoder maps each Base64 character back to six bits, regroups the bits into bytes, and removes padding. If the encoded string contains whitespace or line breaks, many decoders ignore them. If it contains a character outside the alphabet, the decoder may fail or produce an error.

You do not need to do this by hand. Most programming languages have built-in Base64 functions. The important idea to remember is that the process is fully reversible. Encoding does not lose information. It only changes the representation and increases the size.

Worked Example: Hello Becomes SGVsbG8=

The classic example is the word Hello. In ASCII, each letter is one byte. H is 72, e is 101, l is 108, l is 108, and o is 111. Written in binary, these five bytes form a 40-bit sequence. Base64 splits that sequence into groups of six bits.

The five bytes of Hello are encoded as eight Base64 characters: SGVsbG8=. The first three bytes, Hel, become four characters, SGVs. The remaining two bytes, lo, become three characters plus one padding character, bG8=. The padding equals sign shows that the final group was incomplete. The encoded output has eight characters, while the original has five. That is a growth from five to eight, which is consistent with the 3-to-4 ratio plus padding.

You can verify this with any Base64 encoder. Type Hello, encode it, and you should get SGVsbG8=. Decode SGVsbG8= and you should get Hello back. Try it with Hello world, with a space, and with a short sentence. You will see that the encoded output is always longer than the input, and that decoding always restores the original exactly, as long as the string is copied correctly.

This example also shows why Base64 is not encryption. If you see SGVsbG8= in a file, a quick decode reveals Hello. There is no secret. The same is true for longer strings. A password encoded in Base64 is just a password written in a different alphabet.

Do Not Encode Secrets Thinking They Are Hidden

The most important warning about Base64 is also the simplest. Do not encode a secret to hide it. Do not put an encoded API key in a public repository, a screenshot, a support ticket, or a shared document and assume it is safe. Anyone who sees the string can decode it. Automated scanners also recognize Base64 and decode it routinely.

Real secrets need real protection. Store API keys and passwords in a secrets manager or environment configuration, not in code or in a shared file. Use encryption when data must be unreadable without a key. Use HTTPS when data must travel safely over a network. Use access controls to limit who can see sensitive data at all. Base64 is a transport format, not a security control.

If you discover that a secret was shared in Base64, treat it as exposed. Rotate the key, change the password, and revoke the old credential. Decoding is so easy that you should assume the secret was seen in plain text.

When to Use Base64, and When Not To

Use Base64 when you need to embed a small amount of binary data in a text format, send a small attachment through a text-based system, or share a short binary sample in a message. It is also useful when an API or file format requires text and cannot accept raw bytes.

Do not use Base64 for large files. A large image, video, or archive will become about one-third larger, slower to transfer, and harder to cache. Use a file upload, a storage link, or a binary transfer instead. Do not use Base64 to hide data, to protect passwords, or to avoid access controls. Do not use it as a form of compression, because it does the opposite.

For small web images, consider whether a separate image file is better than a data URI. A separate file can be cached, loaded in parallel, and reused across pages. A data URI can be useful for a tiny icon that is used once, but it makes the HTML or CSS larger and harder to maintain.

Limitations

Base64 has clear limits. It increases size by about 33 percent. It provides no confidentiality, no integrity checking, and no compression. It can be fragile if line breaks, spaces, or missing padding are introduced during copying. Some systems use different alphabets or padding rules, so a string encoded in one variant may not decode correctly in another without conversion.

Base64 also makes data harder for humans to read. A long encoded string is difficult to scan, compare, or debug by eye. For large data, that readability cost is high. For small data, it is usually acceptable.

Frequently Asked Questions

Is Base64 encryption? No. Base64 is encoding. It changes representation, not access. Anyone can decode it without a key. Use real encryption for secrets.

Why does Base64 make files bigger? Because three input bytes become four output characters. Four divided by three is about 1.33, so the output is about 33 percent larger than the input.

What does the equals sign at the end mean? It is padding. It shows that the final group of input bytes was incomplete. One equals sign means two bytes in the final group. Two equals signs mean one byte in the final group.

Can I use Base64 for images on a website? Yes, for very small images, using a data URI. For larger images, a separate image file is usually faster, easier to cache, and easier to maintain.

Conclusion

Base64 is a practical tool for carrying binary data through text-based systems. It uses a 64-character alphabet to rewrite bytes as printable text, and it does so at the cost of about 33 percent more size. It is not encryption, not compression, and not a way to hide secrets. Use it for small, text-safe payloads, and choose direct binary transfer or secure storage when size, performance, or privacy matter more.