Base64 Encoder / Decoder

Where Base64 shows up in real work

Once you start looking, Base64 is everywhere on the web. Data URIs embed small images and fonts directly into CSS and HTML as Base64 strings. HTTP Basic Authentication sends credentials as a Base64-encoded username:password pair in a header. JSON Web Tokens carry their header, payload and signature as three Base64url segments joined by dots. Email attachments travel as Base64 inside MIME messages, and countless APIs accept binary payloads — avatars, signatures, PDFs — as Base64 inside JSON bodies. Kubernetes secrets, TLS certificates in PEM files, and the .p12 bundles mobile developers wrestle with are all Base64 underneath.

The common thread is that all of these channels were built for text. Base64 is the bridge that lets arbitrary bytes cross text-only bridges without corruption: every possible byte value maps into a 64-character alphabet that no mail server, proxy or parser will mangle, strip or reinterpret along the way.

Why Base64 output grows by about 33%

Base64 works in groups of three bytes — 24 bits — and splits each group into four 6-bit chunks, each mapped to one printable character. Four characters represent what three bytes held, so the output is always 4/3 the size of the input: 33% larger, plus up to two padding characters (= or ==) to round the length to a multiple of four.

That overhead is the price of text safety, and it is why Base64 is a terrible compression strategy: encoding a file makes it bigger, not smaller. For large assets, serve the binary directly and reserve Base64 for small embeds where one fewer network request wins.

How Base64 encoding actually works, step by step

The algorithm is simple enough to do by hand. Take the text "Hi": its bytes are 01001000 and 01101001 in binary. Concatenate them and split into 6-bit groups: 010010, 000110, 1001 — padding the final group with zeros to reach six bits. Each 6-bit value (0–63) indexes the Base64 alphabet A–Z, a–z, 0–9, +, /: 16 is S, 6 is G, and the padded group gives k, with an = sign marking the short group. Result: SGk=.

Decoding is the exact mirror — each character maps back to 6 bits, the bit stream regroups into 8-bit bytes, and the UTF-8 bytes become text again. Because the mapping is fixed and public, Base64 obscures nothing; it only reshapes data. That is why this tool warns against treating it as protection: "SGVjcmV0" is not a hidden password, it is the word "Secret" wearing a costume.

The URL-safe variant and UTF-8 pitfalls

Standard Base64 uses + and / — both characters with special meaning in URLs and filenames. The URL-safe variant (Base64url, RFC 4648) swaps them for - and _ and typically omits the = padding, producing strings that survive query parameters, JWT segments and file systems untouched. The toggle above switches this tool between the two alphabets.

The second pitfall is character encoding. JavaScript's btoa() only accepts byte-sized characters, so naive tools throw or corrupt data on anything non-ASCII. This tool encodes text as UTF-8 first, which is why café becomes Y2Fmw6k= and emoji round-trip perfectly. If another tool ever shows you mojibake like café after decoding, it decoded UTF-8 bytes as Latin-1 — the data was fine, the decoding was not.

Padding is the third small gotcha. Strict decoders reject Base64 whose length is not a multiple of four, but URL-safe producers routinely omit the = padding to keep tokens compact. When you paste an unpadded string here, the decoder restores the missing padding automatically before validating — one less reason to edit the input by hand.