What Is Base64? A Clear Explainer for Developers

The problem Base64 solves

Many older and text-oriented systems — email, URLs, JSON, XML, HTTP headers — were designed to carry text, not raw binary. Sending arbitrary bytes through them is unreliable: certain byte values are interpreted as control characters, line breaks, or delimiters, and get stripped, mangled, or truncated. Email in particular historically assumed 7-bit ASCII, so raw binary would not survive the trip intact.

Base64 sidesteps this by re-expressing binary data using a small, universally safe alphabet that no text system treats specially. The result is a string you can drop into an email body, a JSON field, a URL, or an HTML attribute with confidence that it will arrive unchanged. The trade-off is size and readability, not correctness — decoding always reproduces the exact original bytes.

How the encoding works

Base64 works on groups of bits rather than whole bytes. It takes the input three bytes (24 bits) at a time and re-slices those 24 bits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, which indexes into the Base64 alphabet — the 64 characters A–Z, a–z, 0–9, plus “+” and “/”. So every 3 input bytes become 4 output characters, which is exactly why the output grows by a third.

Six bits per character is the whole trick: 2^6 equals 64, so six bits map cleanly onto the 64-symbol alphabet with nothing wasted. To decode, a reader reverses the process — translating each character back to its 6-bit value and repacking four of them into three bytes. Because the mapping is fixed and public, encoding and decoding are fully deterministic and require no key.

Padding and the = character

Input rarely divides evenly into 3-byte groups, and padding handles the remainder. When the final group has only 1 or 2 bytes instead of 3, the encoder still emits 6-bit characters for the bits it has, then appends “=” characters to pad the output to a multiple of four. One leftover byte produces two Base64 characters plus “==”; two leftover bytes produce three characters plus a single “=”.

The “=” is not data — it carries no bits and exists only to signal how many bytes were in the final group, so decoders know how to trim the result correctly. This is also why a Base64 string's length is always a multiple of four. A common variant, base64url (used in JWTs and URLs), replaces “+” and “/” with “-” and “_” and often omits the padding entirely, since those characters are unsafe or superfluous in URLs.

Where you will encounter it

Data URLs are a common sighting: a small image can be embedded directly in HTML or CSS as data:image/png;base64,iVBORw0KG... , inlining the binary file as text so it loads without a separate request. Email attachments are Base64-encoded under the hood by MIME so that binary files survive text-based mail transport. It also appears in HTTP Basic Authentication headers, which Base64-encode the username and password.

JSON Web Tokens (JWTs) are three base64url-encoded segments joined by dots — a header, a payload, and a signature. This is a perfect illustration of Base64's nature: because the header and payload are merely encoded, not encrypted, anyone can decode and read them, which is exactly what a JWT decoder does. The signature is what provides integrity; the encoding provides none.

Why Base64 is not encryption

Base64 provides zero confidentiality. There is no secret key, no algorithm to break — the transformation is a public, reversible lookup that any tool or person can undo instantly. Treating Base64 as a way to hide passwords, tokens, or personal data is a serious and common security mistake; the moment someone sees the string, they can read its contents.

If you need secrecy, use actual encryption (such as AES) or, for passwords, a one-way hash (such as bcrypt or Argon2). Base64 sits alongside those as a separate, complementary step: you might encrypt data and then Base64-encode the ciphertext so it transports as text. Encoding makes bytes safe to move; encryption makes them unreadable to others. Keep the two ideas distinct.

The size overhead

Base64 makes data roughly 33% larger, because 3 bytes become 4 characters (4 ÷ 3 ≈ 1.33). Real-world overhead is a little higher once you account for optional line breaks that some encoders insert every 76 characters, plus the one to two padding characters at the end. For a large file, that expansion is the main reason not to Base64-encode data you do not have to.

The practical guidance: use Base64 when a text-only channel forces it — inlining a tiny icon, encoding an email attachment, packing a token — and avoid it for bulk binary transfer where a binary-capable channel is available. When you do need to encode or inspect a string, our Base64 encoder and JWT decoder run entirely in your browser, so tokens and file contents you paste in are processed locally and never sent to a server.

Frequently asked questions