Base64 Encoder & Decoder — Encode or Decode Instantly

Base64 encoding works by taking three bytes of input (24 bits) and splitting them into four groups of 6 bits each. Each 6-bit group (which can represent values 0-63) is mapped to one of 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /. The resulting output is always four characters for every three input bytes. If the input length is not a multiple of three, padding characters (=) are appended to make the output length a multiple of four. For example, the string "Man" encodes as "TWFu". The alphabet choice matters when the Base64 output will appear in URLs: the standard + and / characters have special meaning in URLs, so URL-safe Base64 uses - and _ instead and typically omits padding. JWT tokens, for instance, use URL-safe Base64 so they can be safely placed in HTTP headers and query strings without additional percent-encoding.

Because Base64 maps every three bytes of input to four ASCII characters of output, it increases the data size by a factor of 4/3, or roughly 33%. This overhead is the price of representation: binary bytes that would be unsafe to transmit as-is are replaced with a larger number of safe ASCII characters. Line breaks (added every 76 characters in MIME-encoded Base64, as required by email standards) can add a small additional overhead. This is why Base64 is not a compression format — it always expands the data. For large payloads, consider whether the overhead is acceptable. In many protocols such as JSON APIs, email attachments, and embedded images in CSS, the 33% size increase is an accepted trade-off for compatibility and interoperability across text-oriented systems.

HTTP Basic Authentication transmits credentials by Base64-encoding the string "username:password" and including it in the Authorization request header: Authorization: Basic dXNlcjpwYXNz. This encoding is NOT encryption — it can be trivially decoded by anyone who can read the header. Basic Auth is safe only over HTTPS, where the entire request including headers is encrypted at the transport layer. The Base64 encoding exists solely because HTTP headers must contain printable ASCII characters, not because it provides any security benefit. Always pair Basic Auth with TLS and never use it over plain HTTP in production systems. Modern authentication systems prefer OAuth 2.0, API keys, or JWT tokens over Basic Auth for new integrations.

Data URIs allow binary files such as images, fonts, and audio to be embedded directly into HTML, CSS, or JavaScript as Base64-encoded strings. The format is data:[mediatype];base64,[data]. For example, a small PNG icon can be embedded as data:image/png;base64,iVBORw0KGgo... directly in an img src attribute or a CSS background-image property. This eliminates an HTTP request for the asset, which can improve perceived performance for very small files. However, Base64 encoding increases the asset size by 33%, and the encoded data cannot be cached independently from the document that contains it. Data URIs work best for tiny assets under a few kilobytes where avoiding the HTTP round-trip outweighs the size and caching overhead.

Many APIs transmit binary data — cryptographic signatures, encrypted blobs, file contents — inside JSON bodies or URL parameters, both of which require text-safe formats. Base64 encoding provides a standard way to include such binary data. JWT (JSON Web Tokens) use Base64URL encoding (a URL-safe variant of Base64) for both their header and payload sections, making the token a printable string that can be passed in HTTP headers and URL parameters without additional encoding. When building APIs that accept file uploads or binary data, accepting a Base64-encoded string in a JSON field is a common alternative to multipart form data, especially for small payloads or when the client is a mobile app or JavaScript frontend where multipart encoding is more complex to implement.