What Is Base64? How to Encode and Decode It

Base64 turns any data into plain text made of 64 safe characters. You meet it in email attachments, data URLs, tokens and API responses. This guide explains what it is for, how it works, what the URL-safe form changes, and the mistakes people make with it, above all treating it as a way to hide information.

What Base64 is for

Many systems were built to carry text, not arbitrary bytes. Email, JSON, XML and URLs can all break or change data that contains control characters or unusual bytes. Base64 solves this by writing the bytes using only letters, digits, plus and slash, which survive almost any text channel. It is a common way to put a small image inside a web page as a data URL, to attach files in email, and to carry binary values inside JSON.

How it works

The method is defined in RFC 4648. The input is read in groups of three bytes, which is 24 bits. Each group is cut into four pieces of 6 bits, and each 6-bit value, from 0 to 63, is looked up in a table of 64 characters: A to Z, a to z, 0 to 9, plus and slash. Three bytes therefore become four characters.

If the input does not divide evenly into threes, the last group is padded with zero bits and the output ends with one or two equals signs, so that the length is always a multiple of four. The text foobar becomes Zm9vYmFy. The text f becomes Zg==, and fo becomes Zm8=. These are the test values given in the standard.

Why the output is bigger

Four characters carry three bytes of data, so Base64 makes the data about a third larger, rounded up to a multiple of four characters. A 30 KB image becomes about 40 KB of text. That cost is acceptable for small items. For large files, sending the bytes directly is better, which is why big images are normally linked rather than embedded.

The URL-safe form

Plus and slash have special meanings in URLs and file names. The standard describes a second alphabet, often called base64url, that replaces plus with a hyphen and slash with an underscore. Padding with equals signs is often left off in this form when the length is known. Tokens such as the parts of a JWT use base64url. A decoder should accept either alphabet, which is what the tool on this site does.

Text, Unicode and the btoa problem

Base64 encodes bytes, not characters. To encode text you must first choose how it becomes bytes, and the usual choice is UTF-8. The browser functions btoa and atob treat each character as one byte, so btoa fails for any character above code 255, such as Hindi letters or an emoji. The solution is to turn the text into UTF-8 bytes first and then encode those. The tool does this, so नमस्ते and 😀 round-trip correctly.

When you decode, the bytes may not be text at all. The Base64 of a JPEG image starts with /9j/. Decoding it to text is meaningless, so the tool says the data is valid Base64 but does not decode to text.

Base64 is not encryption

The most important point is that Base64 hides nothing. Anyone can decode it in a second, with no key. RFC 4648 itself notes that it may visually hide data but gives no confidentiality. A password, API key or personal detail that is Base64 encoded is still exposed. Encoding changes the form of the data; encryption protects it with a secret. If something must be kept private, encrypt it with a proper tool and send it over a secure connection.

Common mistakes

• Treating Base64 as security. It is only a format.
• Using the standard alphabet in a URL without converting plus and slash, which corrupts the value.
• Dropping or adding the equals padding in a system that insists on it.
• Encoding text with btoa and being surprised when non-English characters fail.
• Copying with line breaks or spaces added. Many decoders accept them, but some do not.

When a decode fails, check four things: whether the text was cut off, whether it is the URL-safe alphabet, whether padding is missing, and whether the result is binary data rather than text.

A quick check

You can confirm a result by hand for a short word. The letters hel are the bytes 104, 101 and 108. In binary that is 01101000 01100101 01101100, which regroups as 011010 000110 010101 101100, or 26, 6, 21 and 44. Those look up as a, G, V and s, so hel becomes aGVs. That is the start of aGVsbG8=, the Base64 of hello.

Sources

• RFC 4648: The Base16, Base32, and Base64 Data Encodings
• Base64 (MDN Web Docs glossary)