Base64 Encode / Decode

Base64 solves one problem: moving binary data through a channel that only reliably carries text. Email bodies, JSON string fields, XML documents, HTTP headers, and data URIs in HTML and CSS are all text channels, and raw bytes passed through them get mangled by encoding conversions or interpreted as control characters. Base64 rewrites arbitrary bytes using 64 safe characters (A-Z, a-z, 0-9, plus and slash) so they survive the trip intact.

It is not encryption and offers no confidentiality whatsoever. Anyone can decode a Base64 string instantly, including this page. Treat encoded credentials, tokens, or personal data as fully readable by anyone who sees the string. HTTP Basic Authentication encodes username and password in Base64 purely for transport, which is exactly why it is unsafe over plain HTTP and only acceptable inside TLS.

Base64 packs 3 bytes into 4 characters, so encoded output is about 33 percent larger than the input, plus padding. A 300 KB image becomes roughly 400 KB of text. That overhead decides where Base64 belongs.

It is worth paying for small assets embedded directly in a page. A 2 KB icon inlined as a data URI in CSS saves a whole HTTP round trip, which usually costs more time than the extra 700 bytes. It is not worth paying for large files: inlining a 500 KB hero image blocks the stylesheet or HTML from rendering until the entire blob has downloaded, cannot be cached separately, and cannot be served in a modern format to browsers that support one. The practical cut-off most teams use is a few kilobytes. Above that, link the file and let the browser fetch and cache it.

Standard Base64 uses plus and slash as its last two characters, and both are meaningful in URLs: plus decodes as a space in query strings and slash is a path separator. URL-safe Base64, defined in RFC 4648, substitutes minus and underscore instead. JSON Web Tokens use the URL-safe variant, which is why a JWT segment pasted into a standard decoder can fail or produce garbage. If a decode fails on a token, swap minus back to plus and underscore back to slash first.

Padding is the other common failure. Base64 output is padded with one or two equals signs so the length is a multiple of four. Some encoders strip the padding, including the JWT specification, and strict decoders reject the result. Adding equals signs until the length divides by four fixes it. Line breaks are a third variant: MIME email wraps encoded output at 76 characters, and those newlines must be stripped before a strict decoder will accept the string.