Base64 decoding fails for a small, predictable set of reasons — almost never because the decoder is broken. Once you know what to check, most "invalid Base64" errors take seconds to diagnose.
Padding is wrong or missing
Base64 encodes data in 4-character groups. When the input length isn't a multiple of 3 bytes, the output is padded with = characters so it still comes out in a clean group of 4:
"Hi" → "SGk=" (1 padding character)
"Hi!" → "SGkh" (no padding needed)
"H" → "SA==" (2 padding characters)If padding gets trimmed — a common side effect of pasting from a URL, a config file that strips trailing characters, or a manual copy that missed the last character — decoding fails immediately. The fix is almost always to add back the missing = characters until the length is a multiple of 4.
Copy-paste truncation
Long Base64 strings (an embedded image, a large token) are easy to truncate by accident — a triple-click that doesn't quite select to the end, a terminal that wraps and hides part of the line, a text field with a display limit. The result decodes to garbage or fails outright, and the fix is simply re-copying the complete string from its original source.
Characters outside the Base64 alphabet
Standard Base64 only uses A–Z, a–z, 0–9, +, /, and = padding. Anything else — a stray space introduced by word-wrap, a smart quote from a word processor, a literal newline in the middle of the string — breaks decoding. Our Base64 Decoder tolerates incidental whitespace (spaces, tabs, line breaks are stripped automatically, per the Base64 spec's "forgiving" decode behavior), but any other character outside the alphabet still fails.
Standard Base64 vs the URL-safe variant
This is the single most common cause of "it looks right but won't decode." Base64URL (used in JWTs, filenames, and URL query parameters) swaps two characters — + becomes -, / becomes _ — specifically so the result doesn't need further escaping inside a URL. A standard Base64 decoder given Base64URL input (or vice versa) will fail or silently produce wrong output on any string containing those swapped characters. If you're decoding a JWT segment specifically, use our JWT Decoder instead — it already handles the URL-safe variant.
It's not actually Base64 at all
Base32, hex encoding, and Base64URL all produce superficially similar-looking strings of letters and digits. If a string decodes to nothing meaningful — not an error, just garbled bytes — double check the source actually calls it "Base64" specifically, rather than one of these related-but-different encodings.
The bytes decode fine, but the result isn't valid text
Occasionally decoding succeeds at the byte level but produces text that isn't valid UTF-8 — this happens if you paste the Base64 of binary data (an image, a compressed file) into a text-only decoder. That's not a decoding failure exactly; it's a mismatch between what was encoded and what you're expecting back. Our decoder is scoped to text output and will flag this case explicitly rather than showing you garbled characters.