How to fix invalid Base64: incorrect padding and length

Short answer

Do not fix a Base64 padding error by appending = at random. First identify whether the input is Base64 or Base64URL, remove only transport whitespace, and check its length. A length whose remainder modulo four is one is impossible; remainders two or three are recoverable only when the applicable profile allows padding to be omitted.

What “incorrect padding” means

Base64 represents each three-byte group with four characters. When the final group contains one or two bytes, standard Base64 ends in == or =. The padding is not data. It records how many positions in the last group do not carry another byte.

SG9sYQ== therefore decodes to Hola, while SG9sYQ carries the same data without padding. The second form may be valid under a protocol that explicitly makes padding optional, but it is not a universal assumption. The Base64 and Base64URL converter lets you select the variant and checks the final form before producing text.

Diagnose the length

After ignoring whitespace accepted by the input interface, calculate length % 4:

• Remainder 0 can be complete, although its alphabet and trailing bits still need checking.
• Remainder 2 would need two = characters in a padded representation.
• Remainder 3 would need one = character.
• Remainder 1 cannot represent a complete Base64 block; information is missing or an extra character was introduced.

Never delete characters merely to change a remainder of one. That alters the byte sequence and can disguise truncated input.

Check the alphabet before padding

Standard Base64 uses + and /; Base64URL uses - and _. Compact JWT segments normally use the URL-safe alphabet and omit padding. Replacing the two symbols without checking the source contract may accept data under the wrong rules.

Other invalid forms include = in the middle, more than two padding characters, or data after padding. Completing the length cannot repair these cases. Retrieve the original value or fix the producer instead.

Canonical trailing bits matter too

Two strings can appear to decode to the same bytes even though one has nonzero unused bits in its final character. RFC 4648 requires these pad bits to be zero for a canonical encoding. Strict validation prevents multiple spellings of the same bytes, which matters for signatures, cache keys, and exact comparisons.

A safe repair workflow

1. Keep an exact copy of the received input.
2. Confirm Base64 versus Base64URL and whether the protocol permits omitted padding.
3. Remove only transport whitespace, not characters inside the value.
4. Validate alphabet, padding position, length, and canonical trailing bits.
5. Decode the bytes, then validate UTF-8 separately if text is expected.

For an API, fixing the producer is usually safer than making every consumer guess. Consumer-side normalization is appropriate only when the protocol defines the unpadded form.

Quick examples

TQ== is standard Base64 for M; TQ can be accepted as Base64URL or under an unpadded profile. T=== has excessive padding, T=Q= places it incorrectly, and A has an impossible length. Libraries may report all of them as “incorrect padding,” so a precise diagnosis is more useful than adding equals signs until an error disappears.