Base64 Encoder / Decoder.

What base64 actually does

Base64 takes arbitrary bytes and re-spells them using 64 characters that survive any channel that treats data as text. Three bytes — 24 bits — go in, four 6-bit groups come out, each mapped to A–Z a–z 0–9 + /. When the input is not a multiple of three, the tail is padded with = so the decoder knows where the real bytes stop.

That is the whole trick, and it exists because large parts of the internet are still text-only by contract. SMTP was defined for 7-bit ASCII. HTTP header values cannot carry raw bytes. JSON strings cannot hold a null byte. Base64 buys you a channel-safe representation at a fixed, predictable cost.

The 33% tax

Four characters per three bytes means base64 output is always 4/3 the input size — a flat 33% increase, plus up to two padding characters. A 3 MB image becomes 4 MB of text. Three places where that bill lands and people are surprised:

• ▸ Over the wire. Gzip and brotli claw some of it back for text, but base64 of already-compressed data — JPEG, PNG, WebP, zip — compresses badly, so you eat most of the 33%.
• ▸ In a database. A text column full of base64 blobs is a third larger on disk, in every index that touches it, and in every backup you keep.
• ▸ In an LLM prompt. Base64 tokenizes terribly — a high-entropy character soup fragments into far more tokens than the underlying bytes would suggest. Paste some into the token counter and watch.

Base64 is encoding, not encryption

This has to be said plainly because a surprising amount of production code gets it wrong. Base64 has no key, no secret, and no integrity guarantee. The Authorization: Basic header is nothing but base64 of username:password — that is exactly why Basic auth is only acceptable over TLS. A JWT payload is base64url too, which is why you can read anyone's claims in the JWT decoder without a key. Encoding hides nothing from anyone who has the string. If you need secrecy, encrypt, then base64 the ciphertext for transport.

base64url, and where it is required

+ and / are hostile in URLs: a + decodes back to a space in form-encoded query strings, and a / splits a path segment. RFC 4648 §5 defines base64url, which swaps them for - and _ and usually drops the = padding, since padding has to be percent-encoded as %3D. All three JWT segments use it, as do JWK, WebAuthn, and OAuth PKCE code challenges.

Decoding here normalises - and _ back to + and / and re-adds padding, so you can paste either flavour without thinking about it. The toggle only controls what comes out.

Data URIs vs a second request

A data: URI embeds the asset in the document that references it. You save a round trip; you pay for it in cacheability. Those bytes cannot be cached independently, cannot be served from a CDN edge, cannot be revalidated with an ETag, and are re-downloaded with every copy of the HTML or CSS that carries them — and they are 33% bigger while doing it. The trade only pays off for small, stable, render-blocking assets: a 1 KB SVG icon, a tiny placeholder, a background pattern. Everything else belongs in a separate file behind a long cache lifetime, which is the whole argument in CDN vs cache. That is why the file panel above starts warning at 100 KB.

Why UTF-8 breaks naive encoders

Most half-broken base64 tools call btoa() on the raw string. btoa() is a Latin-1 function: it only accepts code units up to U+00FF. Give it 🚀 and it throws InvalidCharacterError. Give it é and it does something worse — it quietly emits the single byte 0xE9, which is Latin-1, not the UTF-8 pair C3 A9, so the string decodes to mojibake somewhere downstream.

This tool runs every string through TextEncoder first, so é becomes C3 A9 and 🚀 becomes F0 9F 9A 80 before base64 ever sees them. Decoding reverses it — atob to a byte array, then TextDecoder in fatal mode — so a payload that is not valid UTF-8 raises a real error instead of handing you a string full of replacement characters. Try the Unicode sample button and round-trip it both ways.