Base64 is a way of writing any binary data, such as an image, a file or text in any language, using only 64 safe, printable characters. It exists because many systems that move data around, from email to URLs to JSON, were designed for plain text and can corrupt or reject raw bytes. Base64 wraps those bytes in characters that survive the journey intact.
You have almost certainly seen it: long strings of letters and digits ending in one or two equals signs, embedded images in web pages, or the middle part of a login token. This guide explains how Base64 works bit by bit, why it makes data larger, what URL-safe Base64 is, and why it should never be mistaken for encryption. You can experiment with every example using our Base64 encoder and decoder.
How does Base64 encoding work?
Computers store data in bytes of 8 bits. Base64 regroups those bits into chunks of 6 bits instead. Six bits can represent 64 different values (2 to the power of 6), and each value is mapped to one character from a fixed alphabet. Every 3 input bytes (24 bits) therefore become exactly 4 output characters.
Take the word "Man". Its three ASCII bytes are 01001101 01100001 01101110. Split into 6-bit groups, that is 010011 010110 000101 101110, or the numbers 19, 22, 5 and 46. In the Base64 alphabet those are T, W, F and u, so "Man" encodes to "TWFu". Decoding simply runs the process in reverse.
- Values 0 to 25 map to the capital letters A to Z.
- Values 26 to 51 map to the lowercase letters a to z.
- Values 52 to 61 map to the digits 0 to 9.
- Value 62 is + and value 63 is / in standard Base64.
What do the equals signs at the end mean?
Input does not always divide neatly into groups of three bytes. When one or two bytes are left over, the encoder pads the final group with zero bits and adds = characters so the output length stays a multiple of four. "Ma" (two bytes) encodes to "TWE=" and "M" (one byte) to "TQ==".
So one = means the last group held two bytes, and == means it held one. You will never see more than two. Some systems, including JSON Web Tokens, drop the padding entirely because the decoder can work out the missing length on its own.
Why does Base64 make data about 33% bigger?
Because every 3 bytes become 4 characters, encoded output is four-thirds the size of the input, an increase of about 33%. The exact length is 4 × ceil(n ÷ 3) characters for n bytes, so 100 bytes become 136 characters and a 1,000,000-byte file becomes 1,333,336 characters. Some formats, such as email (MIME), also insert a line break every 76 characters, adding a little more.
That overhead is the main reason not to use Base64 unnecessarily. Inlining a large image as a data URI in CSS or HTML makes the page heavier and stops the browser caching the image separately. It is a good fit for small icons or for situations where only text is allowed, not as a general way to ship files.
Base64 and Unicode text
Base64 works on bytes, not characters, so text must first be turned into bytes with a character encoding, almost always UTF-8. Plain English letters take one byte each, but many other characters take more: "é" is two bytes in UTF-8 and encodes to "w6k=", and "café" becomes "Y2Fmw6k=".
This catches out many developers. The browser function btoa() only accepts characters with codes up to 255 and throws an error on most non-Latin text, such as emoji or Chinese characters. The fix is to encode the string to UTF-8 bytes first (for example with TextEncoder) and Base64-encode those bytes, which is what our encoder does automatically.
What is URL-safe Base64?
Standard Base64 uses + and /, which have special meanings in URLs and file paths, and = which is used in query strings. URL-safe Base64 (often called base64url, defined in RFC 4648) swaps + for - and / for _, and usually leaves off the padding. The bytes FB FF encode to "+/8=" in standard Base64 and "-_8" in base64url.
The alternative is to percent-encode a standard Base64 string, turning + into %2B and / into %2F, which works but is longer and harder to read. Our URL encoder and decoder shows how percent-encoding handles these and other reserved characters.
Where is Base64 used?
Base64 appears wherever binary data has to travel through a text-only channel. Some of the most common places you will meet it are:
- Email attachments, which MIME encodes as Base64 so they pass through text-based mail servers.
- Data URIs such as data:image/png;base64,... for embedding small images in HTML or CSS.
- HTTP Basic authentication, where "user:pass" is sent as "dXNlcjpwYXNz" in a header.
- JSON Web Tokens, whose header and payload are base64url-encoded JSON that you can read with a JWT decoder.
- Certificates and keys in PEM files, the blocks between BEGIN and END lines.
- Binary values stored inside JSON, XML or environment variables.
Is Base64 encryption?
No. Base64 is an encoding, not encryption. There is no key and no secret: anyone can decode it instantly, and that is the whole point. A JWT header beginning "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" decodes to plain JSON naming the signing algorithm. Basic authentication credentials are only protected because the connection uses HTTPS, not because they are Base64-encoded.
Hashing is different again. A hash such as SHA-256 is a one-way fingerprint of data that cannot be reversed back to the original, which makes it useful for checking integrity or storing password verifiers. Our hash generator produces those fingerprints.
If data needs to be kept secret, use real encryption, such as AES, and only then Base64-encode the ciphertext if it has to be stored as text. For more utilities like these, see our full set of developer tools.
Key takeaways
- Base64 represents binary data with 64 printable characters, turning every 3 bytes into 4 characters.
- Encoded data is about 33% larger, so use it only where text is required.
- Padding with = keeps the length a multiple of four; URL-safe variants often omit it.
- Text must be converted to bytes (usually UTF-8) before encoding, or non-English characters break.
- Base64 is not encryption: anyone can decode it, so never rely on it to hide secrets.