Base64 troubleshooting guide
Fix Base64 invalid padding and symbol 61 errors
Base64 padding errors come from a length mismatch, misplaced equals signs, copied wrappers, Base64URL values, or a decoder mode that does not match the source.
Why padding matters
Standard Base64 groups bytes into blocks and may add one or two equals signs at the end as padding. Some systems keep that padding, while URL-safe tokens and compact identifiers often omit it. A strict decoder can reject an otherwise familiar-looking value when the final length does not match what it expects.
Example
SGVsbG8gMTAyNGJhc2U
SGVsbG8gMTAyNGJhc2U=
How to repair the value
- Remove spaces, quotes, labels, and surrounding punctuation before checking the padding.
- Count the Base64 characters after cleanup. If the length leaves a remainder of two, try adding two equals signs. If it leaves a remainder of three, try adding one equals sign.
- If the value contains dash or underscore characters, treat it as URL-safe Base64 and normalize the alphabet before using a strict standard decoder.
- Decode the repaired value and verify that the output is the text or bytes you expected, not just a successful parse.
Padding can be optional in some formats
Missing equals signs are not always a bug. Many URL-safe formats omit padding because the decoder can infer the final bytes from the string length. JWT segments, signed URL fragments, and compact API tokens commonly use that style.
The important question is which decoder or protocol receives the value. If the next system expects padded standard Base64, add the padding after cleanup. If the next system expects unpadded Base64URL, changing the value may create a different representation than the protocol expects.
Use padding repair only for inspection
Use padding repair to inspect a copied value, decode a sample, or check whether the bytes are readable text. A successful decode is not proof that a token, signature, or encrypted blob is valid.
When a value is signed, the exact encoded text may be part of what gets verified. Decode a copy for debugging, but keep the original token unchanged when sending it back to the service that issued it.
Rust, Python, and strict decoder messages
Strict decoder errors often point to the exact part of the copied value that needs cleanup. Rust, Python, browser APIs, and command-line tools may describe the same damaged Base64 string with different wording.
If a message mentions an invalid symbol, whitespace, a newline, or an offset, clean the copied text before adding padding. For example, a line-feed byte can appear in an error as symbol 10 when a newline was pasted inside the encoded value.
- Rust base64 crate: check whether standard.decode received spaces, line breaks, or URL-safe characters.
- Python binascii.Error: incorrect padding: remove copied wrappers first, then repair the length modulo four.
- Browser atob: normalize Base64URL values before using a strict standard Base64 decoder.
Common mistakes
- Adding padding before removing quotes, commas, or Bearer prefixes
- Using a standard decoder on an unpadded Base64URL token without normalizing it
- Assuming every missing equals sign means the value is broken
- Editing a signed token and then expecting the original signature to remain valid
Related problems
FAQ
What does Base64 padding look like?
Padding uses one or two equals signs at the end of a standard Base64 string.
How many equals signs should I add?
After cleanup, add padding only when needed to make the length a multiple of four. A remainder of two needs two equals signs, and a remainder of three needs one.
Is unpadded Base64 invalid?
Not always. Some formats intentionally omit padding, especially URL-safe Base64 values used in tokens and links.
Why does a decoder mention invalid symbol 10?
In many decoder messages, symbol 10 is a newline byte. Remove accidental line breaks or copied whitespace, then check the Base64 alphabet and padding again.