Base64 Decode Errors: Causes and Fixes

Almost every Base64 failure is one of five things: an illegal character, missing or extra padding, truncated data, Base64URL and standard alphabets mixed, or a data: URL prefix left in place. Each one has a distinct error message — here is what they mean and the fastest way to fix it.

Length must be a multiple of 4 — 1 left over means truncated data
Padding = only appears at the very end (at most two)
data: URL prefixes are not part of the data
Paste it into the tool above to see which one you hit
Repairs are reported, never applied silently

b64file — converter · local

Processed as you paste — no button to press (Ctrl+Enter converts now / Esc clears)

Paste, drag and drop, or Ctrl+V a screenshot

[01]

1. Illegal characters

Standard Base64 uses A-Z, a-z, 0-9, +, / and the padding =. Anything else — a space in the middle, a smart quote from a chat app, a truncated emoji, a stray newline inside the string — makes the whole input invalid.

The usual culprits: copying from a rendered web page instead of the raw response, a chat client that "helpfully" adds line breaks, or a spreadsheet that auto-formatted the cell.

Fix: copy from the raw source. If the data has line breaks that are legitimate (MIME wraps at 76 characters), the converter strips them for you and reports the exact position of anything that is still wrong.

[02]

2. Missing or extra padding

Base64 lengths must be a multiple of 4, and the encoder adds = to fill the gap (one or two characters, never more). When a string is copied by hand the trailing = are the first thing to get lost.

Fix: use the Base64 to file tool — missing padding is restored and excessive padding is trimmed, so you never count characters by hand.

[03]

3. Truncated data (length mod 4 == 1)

If the length leaves a remainder of 1 after dividing by 4, the data cannot possibly be complete — no valid Base64 string ends that way. The remainder is 1 only when bytes were lost, which is why this message always means truncation rather than a formatting problem.

Common causes: a copy that stopped early inside a browser console, a log line cut off at a maximum length, a database column too small for the stored string.

Fix: this one cannot be repaired — the bytes are gone. Re-fetch the data from the source, or export it programmatically rather than copying it through a UI.

[04]

4. Base64URL mixed with the standard alphabet

URL-safe Base64 replaces + with - and / with _, and usually omits padding. JWT segments and URL parameters use that alphabet, while most APIs and file dumps use the standard one. Mixing them, or forgetting which variant you are holding, produces an illegal-character error on a string that looks perfectly fine.

Fix: the tool detects the URL-safe alphabet and maps it back automatically. For the details, see Base64URL and the URL-safe alphabet.

[05]

5. data: URL prefix left in place

data:image/png;base64, is not part of the data — it is the marker in front of it. Feeding the whole string to a decoder without stripping the prefix fails on the first character.

Fix: the conversion tool removes the prefix for you and remembers the MIME type for naming the output. See also Data URL generation and parsing.

Frequently asked questions

Does a length remainder of 1 always mean the data is corrupt?

Yes for standard Base64. A remainder of 1 cannot be produced by a valid encoder, so it always indicates missing bytes rather than a formatting quirk.

Decoding succeeded but the file will not open — how is that possible?

The characters were valid but the bytes are not a complete file: the Base64 was cut at a multiple-of-4 boundary, or the content is something other than what the name suggests. The tool reports the detected type from the file header so you can tell the two apart.

Is there a tool that repairs this automatically?

The converter on this page fixes padding, line breaks, BOMs, data: prefixes and the URL-safe alphabet automatically, then reports anything that genuinely cannot be repaired — like truncated data.