Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text.

About Base64:

  • Encodes binary data into ASCII using 64 characters
  • Output is ~33% larger than input
  • Common in email, data URIs, and APIs

How Base64 Encoding Works

Base64 encoding converts arbitrary binary data into a safe ASCII text string using a 64-character alphabet: Aโ€“Z (26), aโ€“z (26), 0โ€“9 (10), plus + and / (2). The algorithm takes three input bytes at a time โ€” 24 bits โ€” and splits them into four 6-bit groups. Each 6-bit value (0โ€“63) maps to one character in the alphabet, producing four output characters for every three input bytes.

When the input length is not a multiple of three, one or two = padding characters are appended so the output length is always a multiple of four. For example, the string "Man" encodes as "TWFu" with no padding, while "Ma" encodes as "TWE=" and "M" encodes as "TQ==".

Size Overhead

Output size = ceil(n / 3) ร— 4 bytes, where n is the number of input bytes. This gives approximately 33% overhead โ€” a 3 MB image becomes roughly 4 MB as Base64 text. The encoded output is always divisible by 4 due to padding.

Common Use Cases

Base64 appears wherever binary data must travel through text-only channels. Data URIs embed images directly in HTML or CSS: data:image/png;base64,iVBORw0K... eliminates a separate HTTP request. HTTP Basic Authentication encodes credentials as Base64(username:password) in the Authorization header โ€” though this is encoding, not encryption. Email standards (MIME) use Base64 to transmit attachments through mail servers that only handle 7-bit ASCII. JSON Web Tokens (JWTs) encode their header and payload as URL-safe Base64 to pass structured data in compact form.

The URL-safe variant replaces + with - and / with _, and typically omits padding, so the string can appear in URLs without percent-encoding those characters.

Encoding vs Encryption

Base64 is an encoding scheme, not a security mechanism. Any encoded string can be instantly decoded without a key. It provides no confidentiality โ€” it merely transforms binary to printable characters for transport compatibility. For sensitive data, always use proper encryption (AES, TLS) in addition to or instead of Base64 encoding.

Worked Examples

Example 1: Encoding a short string

The three ASCII characters "Man" have byte values 77, 97, 110 โ€” in binary: 01001101 01100001 01101110. Concatenating yields 24 bits: 010011010110000101101110. Split into four 6-bit groups: 010011 (19 = T), 010110 (22 = W), 000101 (5 = F), 101110 (46 = u). The result is "TWFu" โ€” no padding needed because the input was exactly three bytes.

Example 2: Short input requiring padding

Encoding "Ma" (two bytes, 16 bits) falls two bits short of a 6-bit group boundary. The encoder pads the bitstream with zero bits up to the next multiple of 6, then adds a single "=" to the output to signal one byte of padding. Result: "TWE=". The single "M" (one byte, 8 bits) needs four zero bits of padding and two "=" characters: "TQ==". You will never see three "=" at the end โ€” that would imply zero input bytes.

Example 3: Data URI for a small image

A 4 KB PNG icon encodes to roughly 5.5 KB as Base64 text, which embeds inline in CSS: background-image: url(data:image/png;base64,iVBORw0KGgo...). The ~33% size overhead is the trade-off for saving a full HTTP round-trip. Data URIs are most valuable for icons below ~10 KB; larger images are better served as separate files so the browser can cache them.

Example 4: HTTP Basic Authentication

The header Authorization: Basic YWRtaW46cGFzczEyMw== is the Base64 encoding of the string "admin:pass123". Anyone who captures this header can decode the credentials instantly โ€” Basic Auth is always used over HTTPS because Base64 provides zero confidentiality. The encoding exists only so binary username/password data can travel safely through a text-only HTTP header.

Common Pitfalls

  • Treating Base64 as encryption. It is trivially reversible without a key. Never use it to "hide" passwords, API tokens, or sensitive data.
  • Forgetting URL-safe variants. Standard Base64 uses + and /, both of which have special meaning in URLs. Use the URL-safe alphabet (- and _) when the string will appear in a query string or path segment.
  • Missing or stripped padding. Some encoders omit "=" padding. Most decoders accept both, but strict implementations require the padding โ€” add "=" back to make the total length a multiple of 4.
  • Double-encoding. Running encode twice inflates size by ~78% and produces gibberish on decode if the chain is broken somewhere. Track whether data is already encoded before passing it to another layer.
  • Using Base64 for large files. The 33% overhead becomes significant above a few hundred KB. For attachments, images, or binary blobs over ~100 KB, prefer multipart uploads or signed URLs.

Frequently Asked Questions

Is Base64 the same as hex encoding?

No. Hex uses 16 characters (0โ€“9, Aโ€“F) with 50% overhead โ€” each byte becomes two hex digits. Base64 uses 64 characters with only 33% overhead. Hex is easier to read byte-by-byte; Base64 is more compact but less visually parseable.

Why does Base64 sometimes include newlines?

MIME (RFC 2045) requires a line break every 76 characters for email compatibility. Data URIs and JSON bodies typically omit line breaks. Most decoders tolerate both, but strict ones may reject embedded whitespace โ€” strip newlines before decoding if you hit errors.

Can I encode binary files like PDFs and images?

Yes โ€” Base64 was designed for arbitrary binary data. Any file can be read as raw bytes and encoded. The output is safe to paste into JSON, XML, HTML, or email. Most programming languages provide base64_encode / base64_decode functions in their standard libraries.

What is the difference between Base64 and Base64URL?

Base64URL (RFC 4648 ยง5) substitutes - for + and _ for /, and often omits padding. JWT tokens use Base64URL so they can pass through URLs without percent-encoding. Standard Base64 is not URL-safe and must be percent-encoded to appear in URLs.

Why does the encoded string look longer than expected?

Base64 is always a multiple of 4 characters after padding. A 10-byte input encodes to ceil(10/3) ร— 4 = 16 characters. Plan for roughly 1.37ร— the input size when sizing database columns or transmission buffers.

Related Calculators

View all Developer Tools โ†’

Disclaimer

This calculator is provided for educational and informational purposes only. While we strive for accuracy, users should verify all calculations independently. We are not responsible for any errors, omissions, or damages arising from the use of this calculator.


Also in Technical