How Base64 works
Base64, specified in RFC 4648, turns arbitrary bytes into text that uses only 64 safe characters: A-Z, a-z, 0-9, + and /. It works on groups of three bytes (24 bits) at a time, splitting them into four 6-bit values, and each value indexes into that 64-character alphabet. Because three bytes become four characters, the output is about 33% larger than the input.
If the input length is not a multiple of three, the final group is padded with = so that the output is always a multiple of four characters.
Worked example
| Input | Bytes | Base64 |
|---|---|---|
Man | 3 | TWFu |
Ma | 2 | TWE= |
M | 1 | TQ== |
Hello, World! | 13 | SGVsbG8sIFdvcmxkIQ== |
café ☕ | 9 (UTF-8) | Y2Fmw6kg4piV |
The last row shows why encoding is not just about letters. The text is first converted to UTF-8 bytes (é takes two bytes and ☕ takes three), and Base64 encodes those bytes. This tool does that conversion before encoding and reverses it when decoding, so accents and emoji round-trip correctly. The browser's bare btoa function would throw an error on them.
What this tool accepts
It uses the standard alphabet from section 4 of the RFC. The URL-safe variant in section 5 replaces + and / with - and _, and is what JWTs use. If you paste URL-safe text and see "Input is not valid Base64", swap those two characters back first, or use the JWT decoder for tokens. Surrounding whitespace is trimmed before decoding. The tool does not insert line breaks every 76 characters, which MIME email (RFC 2045) requires.
Common mistakes
- Treating Base64 as security. It is a reversible encoding with no key. Anyone can decode it, so it hides nothing. Hashes and encryption are different tools; see the hash generator.
- Decoding binary as text. If the original data was an image or a file rather than text, decoding it here produces garbled characters, because the bytes are not valid UTF-8. For images, use image to Base64, which produces a data URI.
- Dropping the padding. Some systems strip trailing
=signs. Re-add them if a strict decoder complains. - Encoding twice. "Hello" encodes to
SGVsbG8=, and encoding that again gives a string startingU0dWc2JH. If a decode result still looks like Base64, it was probably encoded twice.
Where you will see it
Common places are HTTP Basic authentication headers (username:password encoded), data URIs for small inline images, email attachments, and the three dot-separated segments of a JWT. If the decoded result looks like JSON, paste it into the JSON formatter. For percent-encoding in URLs, which is a different scheme, use URL encode/decode.