Base64 Encoder/Decoder

Base64 is a binary-to-text encoding scheme that converts arbitrary binary data into a string of printable ASCII characters. The name comes from the fact that the encoding uses exactly 64 distinct characters: the 26 uppercase letters A–Z, the 26 lowercase letters a–z, the 10 digits 0–9, and the two symbols + and /. A special padding character = is appended when needed to make the output length a multiple of four.

Base64 was designed to solve a fundamental compatibility problem in data transmission. Many communication protocols and file formats were originally built around 7-bit ASCII text, meaning raw binary bytes above 127 — or even special control characters — could be corrupted, stripped, or misinterpreted during transport. By representing every three bytes of binary input as four printable ASCII characters, Base64 guarantees that data travels safely through any text-only channel, including email servers, XML documents, JSON APIs, and HTML attributes.

It is critical to understand that Base64 is an encoding, not an encryption. The transformation is entirely reversible and provides zero confidentiality. Anyone with a Base64 decoder can retrieve the original data instantly without any key or password. Use Base64 for safe transport and storage, never as a security measure.

The encoding process works on groups of three bytes at a time. Each group of 24 bits is divided into four 6-bit chunks. Each 6-bit value (ranging from 0 to 63) is then mapped to one character in the Base64 alphabet table. If the input byte count is not a multiple of three, one or two = padding characters are appended to complete the final group to four output characters.

This calculator uses the browser-native btoa() and atob() functions combined with encodeURIComponent and unescape to handle Unicode text correctly. Standard btoa() only accepts Latin-1 (ISO 8859-1) strings, so the encoding pipeline first calls encodeURIComponent() to percent-encode multibyte Unicode characters into safe byte sequences, then unescape() converts those percent-encoded sequences into a Latin-1 compatible string that btoa() can safely process.

Standard Base64 uses the characters + (plus) and / (slash) as the 62nd and 63rd alphabet characters. Both carry special meaning in URLs: a plus sign in a query string is interpreted as a space, and a forward slash is a path separator. This makes raw Base64 strings unreliable when embedded directly in URLs or HTTP query parameters without additional percent-encoding.

The URL-safe Base64 variant, defined in RFC 4648 §5, solves this by substituting + with - (hyphen) and / with _ (underscore) — two characters that have no special meaning in URLs. Padding = characters are also stripped because they can interfere with some URL parsers.

This calculator applies the URL-safe transformation by running .replace(/+/g, '-').replace(///g, '_').replace(/=+$/, '') on the standard Base64 output. When decoding URL-safe input, the tool reverses the substitution (-→+, _→/), then re-adds = padding until the string length is a multiple of four before calling atob(). URL-safe Base64 is the standard encoding for JWT tokens, OAuth 2.0 tokens, and URL-embedded binary parameters.

Base64 encoding appears throughout modern software development in contexts where binary data must be transported or stored as text. Knowing where it is applied helps you use it correctly in your own projects.

• HTTP Basic Authentication: Credentials are formatted as username:password and Base64-encoded before being placed in the Authorization: Basic ... header. For example, admin:password encodes to YWRtaW46cGFzc3dvcmQ=.
• Data URLs in HTML and CSS: Small images, fonts, or other binary assets can be embedded directly in markup as data:image/png;base64,... URIs, eliminating additional HTTP requests for tiny resources.
• Email attachments (MIME): The MIME standard uses Base64 to encode binary attachments so they travel safely through legacy email infrastructure that only supports 7-bit ASCII transport.
• JSON API payloads: When a REST API must carry binary data — such as image bytes, audio clips, or cryptographic keys — inside a JSON body, Base64 encoding converts that binary into a safe JSON string value.
• JWT tokens: Each part of a JSON Web Token (header, payload, signature) is Base64url-encoded, making the full token URL-safe and human-readable when decoded.
• Cryptographic key files: Public and private keys stored in PEM format use Base64 to represent binary key material as readable text that terminals and editors can safely display.

Base64 encoding increases data size by approximately 33.3%. This is because every 3 bytes of input become 4 ASCII characters of output — an expansion factor of 4/3 ≈ 1.333. The size ratio shown by this calculator is computed directly from the encoded and decoded lengths: in encode mode the ratio is (outputLength / inputLength) × 100, and in decode mode it is (inputLength / outputLength) × 100, both expressed as a percentage and rounded to one decimal place.

For small data items such as short tokens, API keys, or credential strings, the 33% overhead is negligible. For large binary files such as images or audio, however, the size increase has meaningful consequences: a 1 MB image becomes roughly 1.37 MB when Base64-encoded. Embedding large images as data URLs in HTML is generally discouraged for this reason, as the inflated payload increases page-load time and HTTP transfer costs.

Modern HTTP compression (gzip or Brotli) applied on top of Base64-encoded text can recover much of the overhead, because Base64 output has predictable, compressible character patterns. Most web servers compress responses automatically, mitigating the size penalty for network transfer. However, in-memory footprint and on-disk storage are still affected. For performance-critical applications, consider alternatives such as binary protocol buffers or multipart form-data for large binary payloads, reserving Base64 for the specific interoperability contexts where it is genuinely required.