Base64 Encode / Decode

Base64, fully explained: encoding rules, padding, the 33% size penalty, and common myths

What Base64 actually does

Base64 remaps arbitrary binary data onto 64 printable characters: A-Z, a-z, 0-9, plus + and /. The mapping works in fixed chunks: every 3 bytes of input (24 bits) are split into 4 groups of 6 bits, and each group is looked up in the alphabet to produce one character. That is why the output length is always exactly 4/3 of the input length — there is no rounding, no per-character variation, just a fixed ratio.

The reason Base64 exists is not to hide data but to carry it through channels that only accept text. Email bodies over SMTP, HTTP headers, JSON string fields, XML text nodes, and URL query strings all choke or rewrite bytes that are not printable ASCII. Base64 turns any byte sequence into a character set those transports can hold without damage. Think of it as a courier that repackages a parcel so it fits through a narrow slot — the contents are unchanged, only the wrapping is different.

Where the = padding comes from

Input length is not always a multiple of 3, so the final block may be short. The encoder pads up to 4 characters using = to signal where the original data ended:

The padding carries no information — it only marks "the original data stopped here." Some systems strip it to save space, but once stripped the length is no longer divisible by 4, and the decoder must reconstruct the padding before it can parse. Base64 padding is optional on the wire, but the decoder's handling of it must be correct, or you get a corrupted final byte. If you have ever seen a Base64 string that decodes fine except for a garbage last character, a missing or miscounted = is the usual cause.

The size penalty: not "about the same," but a real 33%

The 4/3 ratio means a volume increase of roughly 33.3%. A 300 KB image encoded as Base64 becomes about 400 KB. Stack a couple of layers — Base64 inside JSON inside another Base64 — and the bloat compounds multiplicatively, not additively.

That overhead creates several concrete traps in everyday engineering:

• Cookies: a single cookie is normally capped around 4 KB, so after Base64 you only have about 3 KB of raw payload to work with. Squeezing a long token in there silently loses data.
• Inlining into HTML/CSS: a data URI inflates the page and cannot be cached independently by the browser — it re-downloads with the host document every time. Small icons and font subsets are worth inlining; a few-hundred-KB image is not.
• Database columns: storing binary as Base64 text degrades both storage efficiency and indexing. The database's native binary type is almost always the better choice.

URL-safe variants: why + and / get swapped

The standard Base64 alphabet contains + and /, both of which carry special meaning inside URLs (they stand in for spaces and path separators). Drop them straight into a URL and they get re-encoded or truncated. RFC 4648 section 5 defines the URL-safe variant:

The catch: Base64 and Base64url produce different output and cannot decode each other. Feed the - and _ of a JWT to a decoder that only knows the standard alphabet and you get garbage. This tool supports both flavors so you can round-trip either one correctly.

Base64 is not encryption, and not a hash

These three concepts get conflated constantly, yet they are completely different in nature:

Anyone can decode Base64. Running a password, an API key, or a national ID number through Base64 before sending it is identical to sending it in plaintext. Open the browser console, type one line of atob(), and the original is back. If you truly need secrecy, transport it over TLS or use authenticated encryption such as AES-GCM.

A checklist of common mistakes

• Double encoding: when decoding fails, the first instinct is often "decode it again," which corrupts a result that was already correct. First determine how many layers of encoding are actually present.
• Treating newlines as data: MIME Base64 inserts a newline every 76 characters. If you do not strip whitespace before decoding, you get an "invalid character" error.
• Assuming bytes equal characters: YQ== decodes to byte 0x61, which is the letter a and also ASCII 97, but it is not the text representation of the number 97. Base64 restores bytes, not characters — text that was not UTF-8 encoded must be reinterpreted with the correct charset after decoding.
• Using it as a security measure: see the section above.
• Using the standard alphabet directly in a URL: / is parsed as a path separator and + inside a query parameter may be rewritten as a space.

When to reach for it, and when not to

Use it to embed binary data into text protocols (JWTs, email, XML, JSON), inline small icons into CSS, log binary fragments safely, or build a Basic Auth header. Do not use it to transmit sensitive data (use TLS), store passwords (use bcrypt or argon2), move large files over HTTP (use multipart or raw binary to reclaim that 33% of bandwidth), or in any compression pipeline where you forgot to compress before encoding — reverse the order and the compression does nothing.

Everything here runs locally in your browser; nothing is sent anywhere. When processing a large file, open the Network panel in your dev tools to confirm there are no outbound requests.