What the error means
Base64 works in blocks: every 3 bytes of input become 4 characters of output. When the input length is not a multiple of 3, the final block is completed with one or two = characters, so a valid standard Base64 string always has a length divisible by 4. Incorrect padding means the string's length breaks that rule, or the = characters are in the wrong place — in the middle, or more than two of them.
The example is Hello world (11 bytes) encoded and then stripped of its padding: 15 characters instead of 16. It is perfectly recoverable; the decoder just needs to be told that the missing = is expected.
Why it happens
- Padding stripped on purpose. The URL-safe variant used by JWTs, and by most APIs that put tokens in URLs, omits
=because it would be URL-encoded to%3D. Decoding such a token in strict standard mode fails on length. - Truncation. A token cut off by a column limit, a log line, or a database field one character too short.
- Padding lost in transit: a form that trims trailing
=, or a URL that dropped them. - Padding in the middle, which happens when two Base64 strings are concatenated without decoding first.
- Whitespace counted in the length, which is really the previous error in disguise.
How to fix it
- Paste the text into the tool above. If the length is one or two short of a multiple of 4, append
=accordingly (one=for a remainder of 3,==for a remainder of 2). Many decoders, including this one in repair mode, add it automatically. - If the remainder is 1, the text is not a valid Base64 length at all: one character cannot encode any whole bytes. The string was truncated by at least one character; recover it from the source.
- If the text is a JWT segment or came from a URL, switch to URL-safe mode, which expects no padding.
- If
=appears anywhere but the end, split the text at that point; you have two encoded values joined together.
The example with padding restored:
SGVsbG8gd29ybGQ=
If it still fails
- Decode to hex with Text to Hex once the padding is fixed; if the bytes look wrong, the text was corrupted before it was encoded, not during.
- Python's
binascii.Error: Incorrect paddingis the same condition and the same fix; add=* (-len(s) % 4) before decoding. - JWT segments never carry padding; JWT Decoder accounts for that automatically.
Related errors
Invalid Base64 character
Switch to URL-safe mode for tokens containing - or _, strip line breaks and spaces, and URL-decode text that contains %2B or %2F before decoding.
URI malformed
Decode to bytes or a file instead of text when the payload is an image, a PDF, or a compressed blob; for text in another encoding, convert from that encoding rather than UTF-8.