You have almost certainly seen Base64 without knowing it: the long jumble of letters, digits, plus signs, and slashes tucked inside an email attachment, a web page image, or an API token. It looks like gibberish, but it is one of the most useful tricks in computing — a way to turn any binary data into plain, safe text.
Why binary data can't travel as plain text
Computers store everything as bytes, and a byte can hold any value from 0 to 255. Text systems, on the other hand, were built for a much smaller set of characters: letters, digits, punctuation, and line breaks. The two worlds collide whenever binary data has to pass through a system designed for text.
Email is the classic example. The original email standards only guaranteed safe delivery for a limited set of printable characters. A photo, a PDF, or an audio clip contains bytes that email servers might mangle, drop, or interpret as control commands. The same problem appears in URLs, which reserve characters like slashes and question marks, and in JSON APIs, which cannot carry raw binary at all.
Base64 solves this by translation. It re-encodes arbitrary bytes using only 64 safe characters: uppercase A–Z, lowercase a–z, digits 0–9, plus + and /, with = as padding. The result is pure text that survives email, URLs, config files, and APIs untouched.
How Base64 works: 6 bits at a time
The name gives away the method. Standard binary works in 8-bit bytes. Base64 regroups those bits into 6-bit chunks, and each 6-bit chunk maps to one character in the 64-character alphabet. Six bits can represent 64 values (2 to the power of 6), which is exactly the size of the alphabet.
The process runs in groups of three input bytes. Three bytes hold 24 bits, which split neatly into four 6-bit groups, producing four output characters. That 3-to-4 ratio is why Base64 output is roughly 33% larger than the input — a cost you accept in exchange for safe transport.
When the input length is not a multiple of three, the final group is short. Base64 pads it with zero bits and marks the missing characters with = signs: one = if the last group had two bytes, two = signs if it had one byte. The padding tells the decoder exactly how many real bytes were in that final group.
Worked example: encoding "Hi"
Let's encode the two letters "Hi" by hand. In ASCII, "H" is 72 and "i" is 105. In binary, that is 01001000 and 01101001 — sixteen bits total.
Split those sixteen bits into 6-bit groups: 010010, 000110, 1001. The last group has only four bits, so pad it with two zero bits to make 100100. Now look up each group in the Base64 alphabet: 010010 is 18, which is "S"; 000110 is 6, which is "G"; 100100 is 36, which is "k". That gives "SGk" — but Base64 output must be a multiple of four characters, so one = is added for padding. The final result is SGk=.
Try a longer word to see the pattern without padding: "Hello" is five bytes, which splits into one full 3-byte group plus a 2-byte group, giving SGVsbG8=. And a three-letter word like "Man" encodes cleanly with no padding at all: TWFu. If you remember one demo, make it that one — "Man" to "TWFu" is the textbook example for a reason.
Where you actually see Base64
Base64 shows up in more places than most people realize:
- Email attachments (MIME). When you attach a file to an email, your mail app Base64-encodes it into the message body so it survives every server hop. Open a raw email source and you will see long Base64 blocks between MIME boundaries.
- Data URIs in web pages. A small image can be embedded directly in HTML or CSS as
data:image/png;base64,...instead of a separate file. This saves a network request but bloats the page, so it is best for tiny icons, not photos. - API tokens and JWTs. JSON Web Tokens encode their header and payload in Base64 (URL-safe variant). Anyone can decode and read them — which is precisely why tokens should never contain secrets.
- Config files and basic auth. HTTP Basic Authentication sends
username:passwordBase64-encoded in a header. Again, this is encoding, not protection — it must travel over HTTPS to mean anything.
Three things Base64 is not
Base64 gets mistaken for things it is not, and each mistake has consequences:
- It is not encryption. There is no key, no secret, and no effort required to decode it. Encoding a password in Base64 and calling it "hidden" is like writing a note in a simple substitution cipher and calling it locked.
- It is not compression. Base64 makes data bigger, not smaller — about a third bigger. If you need smaller data, compress it first, then encode the compressed result.
- It is not a file format. Base64 is a transport wrapper. The decoded bytes might be a PNG, a PDF, or a ZIP file — the encoding itself says nothing about what the content is.
The mental model that keeps you safe: Base64 is a shipping container. It protects data from rough handling in transit, but anyone at the destination can open it.
Frequently asked questions
Is Base64 encryption?
No. Base64 is an encoding, not encryption. Anyone can decode Base64 instantly with no key or password, so it provides zero secrecy. Never use it to hide passwords, tokens, or personal data — use real encryption for that.
Why does Base64 output sometimes end with = signs?
The = signs are padding. Base64 processes input in 3-byte groups, and if the final group has only one or two bytes, padding fills the output to a multiple of four characters. One = means two input bytes in the last group; two = signs mean one input byte.
Why is Base64 output about 33% bigger than the input?
Every 3 bytes of input (24 bits) become 4 Base64 characters, and each character is stored as a full byte of text. That 4-for-3 ratio is a 33% size increase. It is the price of making binary data safe to send as text.
What is URL-safe Base64?
Standard Base64 uses + and / characters, which have special meanings in URLs, and = padding that must be escaped. URL-safe Base64 swaps + for a hyphen, / for an underscore, and usually drops the padding, so the output can sit directly in a web address or token.