glunty Base64 shows up everywhere: data URIs in CSS, attachments in email, tokens in JSON, image blobs pasted into HTML. It looks like gibberish (TWFu, SGVsbG8=) and people often assume it is doing something clever or secret. It is not. Base64 is a plain, reversible way to write binary data using only printable text characters. This guide explains what it does, why it exists, and the details that trip people up.
What Base64 actually is
Base64 is an encoding that represents arbitrary binary data using 64 ASCII characters: A-Z, a-z, 0-9, and two symbols (+ and / in the standard alphabet). Sixty-four characters is exactly 2 to the 6th power, which means each character carries 6 bits of information.
The core mechanic: take 3 bytes of input (24 bits), split those 24 bits into four groups of 6 bits, and map each group to one of the 64 characters. So every 3 bytes of binary become 4 text characters.
Concrete example. The three-letter string Man is bytes 77, 97, 110, or 01001101 01100001 01101110 in binary. Regroup those 24 bits into six-bit chunks: 010011 010110 000101 101110, which are the values 19, 22, 5, 46. Look those up in the alphabet and you get T, W, F, u. So Man encodes to TWFu. Decoding reverses the process exactly.
Why Base64 exists
Many systems were built to move text, not raw bytes. Email bodies, URLs, XML and JSON fields, HTTP headers, and older network protocols expect printable characters and treat certain byte values (null, control codes, newlines) as special or invalid. Send raw binary through one of those channels and it gets mangled or rejected.
Base64 solves this by re-expressing binary in a small, safe character set that survives text-only transport untouched. That is why you see it in email attachments (MIME), in data: URIs that embed an image directly in a stylesheet, in Basic Authentication headers, and anywhere binary needs to ride inside a text field.
Padding with =
Base64 works in blocks of 3 input bytes producing 4 output characters. But input is not always a multiple of 3 bytes. When the last block is short, the encoder pads.
- 1 leftover byte produces 2 characters plus
==. Example: the single byteMencodes toTQ==. - 2 leftover bytes produce 3 characters plus one
=. Example:Maencodes toTWE=.
The = character is not part of the 64-character data alphabet; it is a signal that says “this block was short, ignore the extra zero bits I padded with.” Padding keeps the output length a clean multiple of 4, which makes decoding unambiguous.
The URL-safe variant
The standard alphabet uses + and /, and both cause problems inside a web address. + can be read as an encoded space, / is a path separator, and = is used in query strings. Put standard Base64 in a URL and it may get corrupted or require extra escaping.
The URL-safe variant (defined in RFC 4648) fixes this by swapping two characters: - replaces +, and _ replaces /. Padding = is often dropped entirely because the length can be inferred. This is the encoding you see in JWT tokens and query parameters. It decodes to the exact same bytes; only two characters in the alphabet differ.
Encoding is not encryption
This is the point most worth internalizing: Base64 provides zero security. It uses no key, no secret, and no randomness. Anyone who sees cGFzc3dvcmQ= can decode it back to password instantly, and every language ships a decoder.
Base64 obscures data only in the sense that it is not human-readable at a glance. It does not protect it. Never Base64 a password, API key, or personal data expecting confidentiality. If you need secrecy, you need actual encryption, and Base64 is at most the last step you use to package already-encrypted bytes for text transport.
The size cost
Because 3 bytes become 4 characters, Base64 output is about 4/3 the size of the input, roughly a 33% increase. Padding and any line breaks add a little more. A 300 KB image embedded as a Base64 data URI becomes roughly 400 KB of text.
That overhead is the trade you make for safe text transport. For small assets (icons, tiny images) inlining as Base64 can be worthwhile because it saves an HTTP request. For large files the size penalty usually outweighs the benefit, so serve them as normal binary.
Try it and related tools
You can encode or decode any text or file with the Base64 encoder and watch the 3-to-4 expansion happen on real input. If you are wrestling with characters in a web address specifically, the URL encoder handles percent-encoding, which is the URL world’s equivalent trick. And to see the bits underneath any character, the binary to text converter shows the byte values that Base64 is regrouping.
Closing
Base64 is one of the most boring and most useful encodings in computing. It is a mechanical, lossless mapping from bytes to a 64-character text alphabet, built for one job: getting binary data through channels that only handle text. Remember the three facts that matter in practice: it grows data by about a third, the = is padding not data, and it is encoding, never encryption.