Base64 Encoder / Decoder

What Base64 is — and the thing people keep mistaking it for

Base64 is a binary-to-text encoding: it maps arbitrary bytes onto a 64-character alphabet (A–Z, a–z, 0–9, and two symbols) so that data which might contain control characters or bytes a text channel would mangle can travel safely as plain ASCII. That's its entire job. The standard is defined in RFC 4648, and email attachments, data URIs, and JWT segments all lean on it for exactly this reason — to move bytes through systems built for text.

The persistent misconception is that Base64 is a form of security. It is not. There is no key, no secret, and no protection — anyone can decode a Base64 string instantly with a one-line command, and this very tool decodes it for you. Putting a password or an API key in Base64 'to hide it' protects nothing; it's reversible obfuscation at best. If you need confidentiality, you need actual encryption such as AES; if you need an irreversible fingerprint, you need a hash. Base64 is encoding, full stop.

The 33% size overhead, and where it matters

Base64 represents every 3 bytes of input as 4 ASCII characters, which makes the output about 33% larger than the original — a 90 KB image becomes roughly 120 KB of text, plus a few bytes of = padding to round the length to a multiple of four. That tax is the price of text-safety and it's usually fine, but it changes the maths in two places. First, embedding images as data URIs in CSS or HTML inlines that inflated payload into every page load and defeats browser caching, so it only pays off for tiny, frequently-reused assets (a 1 KB icon), not photographs. Second, Base64-encoding a multi-gigabyte file to paste somewhere will balloon it by a third and can run a browser tab out of memory — for huge files a streaming command-line tool is the right call, not a web page.

Standard vs URL-safe, and why the difference exists

Standard Base64 uses + and / as its last two alphabet characters and = for padding. The problem is that all three are special in other contexts: + means space in form-encoded URLs, / is a path separator, and = is a query delimiter — so a standard Base64 string dropped into a URL or filename gets corrupted or needs percent-escaping. The URL-safe variant defined in RFC 4648 §5 swaps + for - and / for _, and padding is often omitted entirely, so the result drops cleanly into URLs, filenames, and the dot-separated segments of a JWT without further escaping. This decoder auto-detects which alphabet you've pasted and ignores stray whitespace, line breaks, and PEM-style header lines, so round-tripping either variant just works.

Practical uses, and where to reach for a neighbour instead

• Data URIs — inline a small icon or font as data:image/png;base64,… to save an HTTP request, but only for tiny, cache-insensitive assets given the 33% bloat.
• Embedding binary in text-only fields — a JSON value, a YAML config, a shell heredoc, an email MIME body — anywhere raw bytes would break the format.
• Inspecting a JWT — the header and payload are URL-safe Base64, so decoding them reveals the claims; but to verify the signature, use the JWT tool, since Base64 alone proves nothing about authenticity.
• Not for percent-encoding a query string — that's a different transform; reach for URL encoding instead. And not for compression — Base64 makes data bigger, never smaller.