A clear explanation of how Base64 encoding works, why it exists and how it's used in APIs, data URIs and authentication.
What Base64 is, how the 3-bytes-to-4-characters encoding works, why padding exists, and where it is used in URLs, email, data URIs and APIs today.
Key points from this guide
Base64 maps every three bytes onto four printable characters, which is why encoded data is about 33% larger than the original.
The = characters at the end are padding, present when the input length is not divisible by three — one = means one leftover byte pair, two = means one leftover byte.
URL-safe Base64 swaps + and / for - and _ so the value can sit in a query string without further escaping.
Base64 is an encoding, not encryption: it has no key and is reversed instantly, so it protects nothing.
Common uses are email attachments (MIME), data: URIs for small inline images, and binary fields inside JSON.
Frequently asked questions
Should I inline images as Base64 data URIs?
Only for very small assets such as icons. The 33% size increase and the fact that data URIs cannot be cached separately usually outweigh the saved request.
Why does a JWT look like Base64?
It is — three URL-safe Base64 segments joined by dots. The payload is readable by anyone; the signature is what makes it trustworthy, not the encoding.