Base64 Encoding Explained: How Bytes Become Plain Text

by Souy Soeng /October 16, 2026

Diagram showing the word Man turned into bytes, split into four 6-bit groups, and encoded as the Base64 text TWFu

Base64 encoding is a simple, reversible way to write any binary data, such as a photo, a PDF or a security key, using only 64 ordinary text characters. If you have ever seen a string like SGVsbG8= and wondered what it was, you have met Base64. That string is just the word Hello, written in a different alphabet.

This guide explains why Base64 exists, how it works inside one step at a time, where you will run into it, and the mistakes people often make with it. You won't need any maths beyond simple counting. By the end, you will be able to encode and decode a short word by hand.

In short

Base64 writes any bytes using 64 safe characters: A–Z, a–z, 0–9, plus and slash.
It reads three bytes (24 bits) at a time and splits them into four 6-bit groups.
Each 6-bit value from 0 to 63 maps to one character, so 3 bytes become 4 characters.
The equals sign pads a short final chunk; output is about a third bigger than the input.
Base64 is for compatibility, not secrecy: anyone can decode it in seconds.

Why do we need Base64 encoding?

Many systems were designed to carry text, not the raw bytes inside files. Early email is the classic example. It was built for plain messages written with a small set of safe characters. A photo, a PDF or a zip file is made of bytes that are not readable characters at all.

When those bytes travel through a text-only channel, servers along the route can alter them, strip them or misread them as special control characters. Changing even one byte can corrupt a whole file. That is why an attachment can arrive as garbage. The same issue appears in modern formats like JSON, which can hold text but not raw bytes.

The fix is to dress the bytes up as text. If every byte is rewritten using characters that every system accepts, the data can pass through untouched and be rebuilt exactly on the other side. That is the whole job of Base64.

Text channels expect readable characters
Binary files contain bytes that are not readable characters
Base64 turns those bytes into characters every system accepts

What is Base64? The 64-character alphabet

Base64 is a way to write any binary data using just 64 plain text characters. It does not care what the bytes mean. An image, a song, a PDF and a security key are all just sequences of bytes, and Base64 treats them all the same way. It also doesn't summarise or squash anything. It spells the same bytes differently, so nothing is lost.

The alphabet is a fixed table where every character has a number from 0 to 63. Think of it as theatre seats numbered from zero to sixty-three, each holding exactly one character. The order never changes, so the sender and the receiver always agree on the table.

Capital and small letters are different characters here. Capital A is 0, while small a is 26. Also be careful not to confuse the character 0, which stands for the value 52, with the value zero itself, which is capital A.

A to Z: values 0 to 25
a to z: values 26 to 51
0 to 9: values 52 to 61
Plus (+) is 62 and slash (/) is 63

Why 64 characters? Six bits per character

Why 64, rather than 26 or 100? Because 64 is exactly the number of different values you can make with six bits. A bit is a zero or a one. Two bits give four patterns, three bits give eight, and each extra bit doubles the count. Six bits give 64 patterns, one for every character in the table.

That means a single Base64 character carries exactly six bits of your data, no more and no less. A byte has eight bits, so three bytes make 24 bits. Twenty-four divides neatly into four groups of six. This is the key ratio: every three bytes of input become four characters of output.

6 bits = 64 possible patterns
1 Base64 character = 6 bits
3 bytes (24 bits) = 4 characters

How Base64 encoding works, step by step

Step one is to read the data three bytes at a time. Every file is already a long row of bytes, and Base64 walks along it picking up three at a time, like taking eggs out of a carton in threes. Take the word Man. In the ASCII table, M is 77, a is 97 and n is 110. In binary these are 01001101, 01100001 and 01101110.

Step two is to cut those 24 bits into four groups of six. Nothing about the bits changes, and their order stays the same. Only the dividing lines move, like re-cutting one loaf into four slices instead of three. The groups are 010011, 010110, 000101 and 101110, which are the values 19, 22, 5 and 46.

Step three is to look each value up in the alphabet. It works like a coat check: ticket 19 gets whatever hangs on hook 19, which is capital T. Then 22 is W, 5 is F, and 46 lands in the lowercase range on small u. So Man becomes TWFu. For longer data, you repeat this for every three bytes until the input runs out.

Because six bits can never make a number above 63, every group is guaranteed to land on one of the 64 seats. That is also why reversing the process is easy: look up each character, rejoin the bits, and read them back as bytes.

Text: M a n
ASCII: 77 97 110
6-bit values: 19 22 5 46
Base64: TWFu

What does the equals sign mean in Base64?

Real data isn't always a multiple of three bytes long. When the last chunk is short, Base64 fills the gap with zero bits and marks the end with an equals sign. This padding tells the decoder exactly how many real bytes were in the final chunk, so nothing extra sneaks into the result.

Take the word Hi. H is 72 and i is 105, which is only 16 bits. Adding two zero bits makes 18, which is three groups of six. Looking those up gives S, G and k. One equals sign is added for padding, so Hi becomes SGk=.

There are never more than two equals signs. If the final chunk has two bytes, you get one. If it has just one byte, you get two. The letter M on its own, for example, encodes to TQ==.

Two leftover bytes: one =
One leftover byte: ==
No leftover bytes: no padding

How to decode Base64 yourself

Now the opening mystery can be solved. SGVsbG8= is five bytes of text, H, e, l, l, o, encoded as eight characters. The first three bytes, H e l, form one full group and become SGVs. The leftover l and o become bG8, and one equals sign pads the end.

You don't need special software, a password or a secret to decode it. Tools for Base64 are built into almost every operating system and programming language. The command below pipes the string into base64 with the decode option and prints Hello. It then goes the other way, encoding Hello back into SGVsbG8=.

That ease is the point to remember. Any computer can reverse Base64 instantly, with no key at all.

# decode the mystery string
echo 'SGVsbG8=' | base64 --decode
# Hello
# and encode it again
echo -n 'Hello' | base64
# SGVsbG8=

Where is Base64 used?

Base64 shows up wherever binary data has to ride inside text. There is always a text format or text channel on one side and some bytes on the other, and Base64 acts as the adapter between them.

Email attachments are the classic case. Your email app encodes the file as Base64 inside the message, under a header that says so, and the receiving app uses that header to rebuild the original file. Data URLs let a web page include a small image directly in its code: the address starts with data, the image type and the word base64, followed by the encoded bytes. JSON payloads are text too, so apps use Base64 to carry bytes inside API messages.

HTTP Basic authentication is another everyday example. When a server asks you to log in, the browser joins the username and password with a colon, for example user:pass, and encodes it as dXNlcjpwYXNz. It sends that in a header starting with Basic. The server decodes it, checks the login and returns the page. The encoding only makes the login fit on one line of text. Anyone who intercepts it can decode it instantly, so the connection must also use HTTPS.

Email attachments
Data URLs in web pages
JSON API payloads
HTTP Basic auth headers

Common Base64 mistakes to avoid

Most Base64 problems come from expecting it to do something it doesn't. The biggest is treating it as protection. A Base64 string looks scrambled, so it feels safe, but it decodes in seconds. Storing passwords or API keys as Base64 is the same as storing them in plain text. For secrecy, use real encryption, and for passwords, use a proper password hash.

The second mistake is forgetting the size cost. Every three bytes become four characters, so encoded data is about a third bigger. A three megabyte image becomes roughly four megabytes of text, which matters when you embed many files or send them often.

The third is mixing variants. The standard alphabet and the URL-safe alphabet differ in two characters, so data encoded with one may not decode correctly with the other. Make sure both sides agree on which variant they use.

Not encryption: never use it to hide secrets
About a third bigger than the original
Standard and URL-safe alphabets are not interchangeable

Base64 vs encryption vs compression

All three turn data into strange-looking output, which is why they get confused. What separates them is the goal, whether a key is involved, and what happens to the size. Base64 is for compatibility with text, needs no key, and grows data by about a third. Encryption is for secrecy, needs a secret key, and keeps the size about the same. Compression is for smaller files, needs no key, and usually shrinks the data.

Familiar examples are email attachments for Base64, HTTPS for encryption and zip files for compression. When you need more than one, a common order is to compress first, then encrypt, then Base64 encode if the result must travel through a text channel. Each step does its own job, and only one.

Base64: compatibility, no key, about a third bigger
Encryption: secrecy, secret key, about the same size
Compression: smaller files, no key, usually smaller

Key takeaways

Text-only channels can't safely carry raw bytes, so Base64 rewrites them as safe characters.
Three bytes make 24 bits, which split into four 6-bit groups.
Each group maps to one of 64 characters: A–Z, a–z, 0–9, + and /.
One or two equals signs pad a final chunk that is shorter than three bytes.
Base64 is not encryption, and it makes data about a third bigger.

Frequently asked questions

Is Base64 a form of encryption?

No. Base64 only changes the form of data so it can travel as text. It uses no key, and anyone can decode it in seconds with built-in tools.

Why does Base64 output sometimes end with = or ==?

The equals sign is padding. It appears when the input length isn't a multiple of three bytes: two leftover bytes give one =, and one leftover byte gives ==.

How much bigger does Base64 make a file?

About a third bigger, because every three bytes become four characters. A three megabyte image becomes roughly four megabytes of Base64 text.

What does SGVsbG8= mean?

It is the word Hello encoded in Base64. The five bytes H, e, l, l, o become eight characters, including one equals sign for padding.

Is HTTP Basic authentication secure because it uses Base64?

No. Base64 only formats the username and password so they fit in one header, and anyone who intercepts it can decode them. The connection must use HTTPS to protect the login.

What is the difference between standard and URL-safe Base64?

The two alphabets differ in two characters. Data encoded with one may not decode correctly with the other, so both sides need to use the same variant.

Watch the full video on YouTube →

Tag

Ad