How Base64 works
Base64 encodes arbitrary bytes as text by taking them three at a time — 24
bits — and splitting those into four 6-bit groups, each mapped to one of 64
printable characters (A–Z, a–z, 0–9, + and /). When the input length is not a
multiple of three, one or two = characters pad the result. That is
why encoded data is always a multiple of four characters and roughly a third
larger than the original. It exists so that binary data can travel safely
through channels built for text, such as email bodies, JSON strings, and data
URIs.
The URL-safe variant
The + and / characters have special meaning in URLs
and filenames, so a URL-safe alphabet replaces them with - and
_ and usually drops the padding. This is what you see inside JSON
Web Tokens (JWTs). The decoder here accepts both alphabets, with or without
padding, so you can paste either form.
Percent-encoding and the "+ means space" myth
URL (percent) encoding is a different scheme: every byte outside a small
"unreserved" set (letters, digits, and - _ . ~) becomes
% followed by two hex digits. A common trap is that +
means a space — but that is only true in application/x-www-form-urlencoded
form data, not in URLs generally. In a real URL, + is a literal
plus sign, and this converter treats it that way.
Why UTF-8 matters
Text is not bytes until you choose an encoding. This tool uses UTF-8, where
ASCII characters are one byte but "é" is two (0xC3 0xA9) and an
emoji is four. Converters that assume one byte per character mangle any
non-ASCII text; here the hex pane shows you the actual bytes, so you can see
exactly what is being encoded. If you paste bytes that are not valid UTF-8, the
text pane shows a best-effort decoding and flags it.
Related tools: the number base converter for turning individual numbers between bases, the hash generator for fingerprinting the same bytes, and the JWT decoder, which decodes the base64url parts of a JSON Web Token.