Encode and decode Base64 data for files and text

Base64 Converter — Encode Binary Data as Text and Decode It Back Anywhere

Base64 encoding solves a specific problem that arises constantly in systems designed for text: binary data (images, audio, arbitrary bytes) cannot be safely transmitted through protocols and systems that interpret certain byte values as control characters. SMTP email, HTTP headers, and XML documents all have reserved byte sequences that would corrupt binary data passed through them directly. Base64 converts binary data to a 64-character alphabet (A–Z, a–z, 0–9, +, /) that contains no reserved characters in any common text protocol, allowing any binary content to be safely embedded in text contexts. The trade-off is size: Base64 encoding increases the size of the original data by approximately 33%.

Practical Base64 use cases appear throughout modern development. CSS data URIs embed images directly in stylesheets as Base64: background-image: url('data:image/png;base64,iVBORw0KGgo...') eliminates an HTTP request for small icons and UI elements. JWT tokens encode their header and payload as Base64url (a variant that replaces + with - and / with _ for URL safety) and concatenate the parts with periods. Basic HTTP authentication encodes username:password in Base64 for the Authorization header — not encryption, just encoding, which is why Basic auth requires HTTPS. Email attachments are Base64-encoded in the MIME multipart envelope before transmission through SMTP servers that cannot handle raw binary.

Base64url versus standard Base64 is a distinction that causes subtle bugs when the wrong variant is used. Standard Base64 uses + and / as its 62nd and 63rd characters — both of which are special characters in URLs and query strings. Base64url substitutes - and _ for these characters, producing strings that are safe in URLs without percent-encoding. JWT tokens use Base64url throughout. URL-embedded images and binary data in query parameters should use Base64url. Using standard Base64 where Base64url is expected — or vice versa — produces decoding failures that appear to be data corruption but are actually encoding variant mismatches. The converter offers both variants with clear labeling so the correct encoding for each context is an explicit choice rather than an assumption.