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.

Open Base64 Error Fixer View all tools

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

Input

SGVsbG8gMTAyNGJhc2U

Output

SGVsbG8gMTAyNGJhc2U=

How to repair the value

  1. Remove spaces, quotes, labels, and surrounding punctuation before checking the padding.
  2. 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.
  3. If the value contains dash or underscore characters, treat it as URL-safe Base64 and normalize the alphabet before using a strict standard decoder.
  4. 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.