Base64 Encode / Decode

The one thing worth saying up front, because people get this wrong constantly: Base64 is not encryption. It provides zero confidentiality. Anyone can decode it in one line of code. All it does is take arbitrary binary data and represent it using 64 characters that are safe to put inside text-based formats — which is exactly why it shows up everywhere from JWTs to email attachments to embedded images.

What it's actually for

• JWTs — the header and payload are both Base64URL, not encrypted. Anyone can decode a JWT and read the claims; the signature is what stops them being forged, not the encoding.
• HTTP Basic Auth — the Authorization header sends username:password Base64-encoded. Again, not secure on its own — this is exactly why Basic Auth is only acceptable over HTTPS.
• Email attachments — MIME can't carry raw binary, so anything non-text gets Base64-wrapped before it goes in the message body.
• Data URIs — embedding a small image directly in CSS or HTML as data:image/png;base64,... instead of a separate file request.

The 33% tax

Every 3 bytes of input becomes 4 characters of output, so encoded data is roughly a third larger than the original. That overhead is invisible for small tokens but adds up fast if you're tempted to Base64-encode something big and stuff it into a database column or an API payload — you're paying extra storage and bandwidth for no functional benefit over just sending the binary properly.

Standard vs URL-safe

Regular Base64 uses + and /, both of which mean something in URLs and get mangled by anything that percent-encodes automatically. Base64URL swaps those for - and _ and usually drops the trailing = padding — which is why JWTs and cookie values use it instead of standard Base64. If you're generating a token that's going into a URL or a cookie, use the URL-safe variant from the start rather than discovering the problem later when a + silently becomes a space.