Understanding the Base64 encoder and decoder — concept and principle
Base64 turns arbitrary bytes into plain ASCII text using 64 safe characters, so binary data can travel through systems built for text: email attachments (MIME), data URLs, JSON fields, HTTP Basic authentication headers and JSON Web Tokens. This tool encodes text to Base64, decodes it back, or produces the URL-safe variant. Text is converted to UTF-8 first, so Korean and other non-Latin characters work, and everything runs in your browser.
How it is calculated
- Convert the text to UTF-8 bytes.
- Split the bytes into groups of 3 (24 bits).
- Split each group into four 6-bit values (0–63).
- Map each value to the alphabet A–Z (0–25), a–z (26–51), 0–9 (52–61), + (62) and / (63).
- If the last group has only 1 or 2 bytes, pad the output with = or == so its length is a multiple of 4.
Output length = 4 × ⌈bytes ÷ 3⌉. The URL-safe mode replaces + with -, / with _ and drops the padding. Decoding reverses the steps and also accepts the URL-safe characters.
The principle
Six bits give exactly 64 combinations, and 64 characters can be chosen that survive almost any text channel unchanged. Three bytes (24 bits) divide evenly into four 6-bit pieces, which is why Base64 works in 3-byte to 4-character blocks and grows the data by about one third. Padding tells the decoder how many bytes the final block really held.
Worked example
- Input: "Hello, 세계!" in Encode mode.
- UTF-8 bytes: "Hello, " is 7 bytes, 세 (EC 84 B8) and 계 (EA B3 84) are 3 bytes each, "!" is 1 byte: 14 bytes in total.
- First block "Hel" = 48 65 6C = 010010 000110 010101 101100 = 18, 6, 21, 44 = "SGVs".
- 14 bytes = four full blocks plus 2 bytes, so 4 × 4 + 4 = 20 characters with one = at the end.
- Result: SGVsbG8sIOyEuOqzhCE=, length 20.
How to read the result
The length is always a multiple of 4 in standard mode. A single = means the last block held 2 bytes; == means it held 1. Decoding garbage or a string with invalid characters gives "invalid input". If decoded text looks garbled, the original bytes were probably not UTF-8 text, for example an image or a file in another character set.
Common mistakes
- Treating Base64 as encryption; anyone can decode it instantly.
- Mixing standard and URL-safe alphabets between systems.
- Encoding text in a non-UTF-8 character set and expecting the same output.
Frequently asked questions
Why does Base64 make data about 33% larger?
Every 3 bytes become 4 characters, a 4 ÷ 3 ratio, plus up to two padding characters.
When should I use URL-safe Base64?
When the result goes into a URL, file name or token such as a JWT, where + and / have special meaning.
Can padding be omitted?
Many decoders accept missing padding, as this tool does, but some strict ones require it.
Sources: IETF RFC 4648, The Base16, Base32, and Base64 Data Encodings · IETF RFC 3629, UTF-8, a transformation format of ISO 10646