Base64 Encoder/Decoder

What is Base64?

Base64 is the binary-to-text encoding defined in RFC 4648. It packs 3 bytes of binary input (24 bits) into 4 ASCII characters drawn from a fixed 64-character alphabet: uppercase A-Z, lowercase a-z, digits 0-9, and the symbols `+` and `/`. When the input length is not a multiple of 3, the encoder pads the tail with one or two `=` characters so the output length is always a multiple of 4. A worked example: the two-byte string “Hi” is hex `48 69`, which Base64 encodes to `SGk=`. That output is three real characters plus one pad. That single pad is the signal that the original payload was 2 bytes, not 3.

How Base64 works

The 33% size overhead is structural, not a quality knob. The 4/3 ratio falls directly out of the encoding rule: every 3 input bytes become 4 output characters, so the output is always 4/3 the size of the input before padding rounds up to the next multiple of 4. There is no lossless way to compress that ratio away while staying within the printable-ASCII guarantee that makes Base64 useful in the first place.

RFC 4648 section 5 defines a URL-safe variant that substitutes `-` for `+` and `_` for `/`, because the standard alphabet's `+` and `/` both carry meaning inside URLs. The URL-safe variant also commonly drops the trailing `=` padding, since `=` is a reserved character in query strings. JWTs (RFC 7519), OAuth state parameters, and any token destined for a URL path or query string travel as URL-safe Base64. Concrete numbers: a 100-byte file encodes to 136 characters of standard Base64 (4 padded blocks of 4) and to 134 characters of URL-safe Base64 once the two trailing `=` are dropped. The savings are small per-token but compound across busy auth endpoints.

Common pitfalls

Three failure modes account for nearly every Base64 bug we see in production code. The encoding is simple, the API surface is small, and yet the same three traps catch new engineers and senior engineers alike. Each one is cheap to avoid once named.

• Treating Base64 as a security mechanism. It is encoding, not encryption: anyone holding the string recovers the plaintext with one function call, no key, no secret. Tokens, passwords, and API keys must be encrypted (AES-256-GCM, libsodium, WebCrypto) before they go anywhere a third party can read them. Base64 around the ciphertext is fine; Base64 instead of the ciphertext is a vulnerability.
• Mixing the standard and URL-safe alphabets between encoder and decoder. A value encoded with `+/` and decoded with the `-_` table will silently corrupt: the bytes come back wrong without raising an exception, because both alphabets are valid input to most decoders. We pick one variant per system boundary and document it.
• Embedding multi-megabyte images as `data:` URIs to save one HTTP request. The 33% overhead inflates the HTML, the parser blocks while it ingests the giant string, the browser image cache cannot dedupe the asset across pages, and Largest Contentful Paint suffers. A CDN URL with a long `Cache-Control` header wins on every repeat visit.

When to use this tool

We reach for the encoder in three concrete situations. The first is inlining a small SVG icon, typically under 5KB, into CSS as a `data:` URI: the round-trip cost of a separate request usually outweighs the 33% size penalty for assets that small, and the icon ships with the stylesheet that uses it. The second is producing a Basic Auth header value: HTTP's `Authorization: Basic` scheme expects `username:password` Base64-encoded, and we paste the literal credential in once, copy the encoded result into a config file, and move on. The third is sanity-checking the middle segment of a JWT during debugging: JWTs are three Base64URL-encoded parts joined by dots, and pasting the payload segment into the decoder reveals the claims as JSON without firing up a full JWT debugger or its npm dependency tree.

Frequently asked

Is Base64 the same as encryption?

No, and conflating the two is the single most common Base64 mistake we see. Base64 is a reversible binary-to-text encoding defined in RFC 4648: anyone with the encoded string recovers the plaintext in one function call, no key required. Use it for transport across text-only channels (email, JSON bodies, URL parameters), never for confidentiality. For real encryption, use AES-256-GCM via `libsodium`, `WebCrypto`, or your platform's authenticated-encryption primitive.

Why is my encoded output longer than the input?

Structural 4/3 expansion ratio, baked into the spec. Base64 packs 3 input bytes (24 bits) into 4 ASCII characters (6 bits each, drawn from a 64-character alphabet). That is a fixed 33.3% size overhead before padding. RFC 4648 then pads the output with `=` characters so the length is a multiple of 4: 1 input byte yields 2 chars + 2 pads, 2 input bytes yield 3 chars + 1 pad. Standard Base64 always rounds to 4-char blocks.

What's the difference between standard and URL-safe Base64?

Alphabet substitution defined in RFC 4648 section 5. Standard Base64 uses `+` and `/` as the 63rd and 64th characters, both of which carry meaning in URLs (space and path separator). URL-safe Base64 substitutes `-` and `_` instead, and commonly omits the `=` padding. JWTs (RFC 7519), OAuth state parameters, and any token destined for a query string use the URL-safe variant. Mixing the two between encoder and decoder produces silent corruption.

Can I encode binary files like images?

Yes, and a small inline icon is a reasonable use case. Worked example: a 4KB PNG encodes to a roughly 5.4KB string, which we drop into CSS as `background-image: url('data:image/png;base64,iVBORw0KGgo...')`. The `data:` URI scheme (RFC 2397) accepts any MIME type with the `;base64` suffix. The 33% size overhead applies to every embedded asset, so we reserve this pattern for assets under about 5KB where saving an HTTP request actually matters.

Should I Base64-encode large images for my website?

No. Inlining a 500KB hero image as a `data:` URI inflates the HTML payload by 670KB after the 33% overhead, which blocks the parser, defeats the browser image cache, and craters Largest Contentful Paint. A CDN URL with a `Cache-Control: public, max-age=31536000, immutable` header is faster on first load and free on every repeat visit. We inline only assets under roughly 5KB: tiny SVG icons, single-color sprites, and the like.