Code Beautifier
Incorrect padding

Fix Base64 "Incorrect padding"

Base64 encodes 3 bytes as 4 characters, so valid length is a multiple of 4, padded with =. Why JWTs and URL-safe tokens omit padding, and the fix.

Input that triggers it

SGVsbG8gd29ybGQ
Draft saved locally.

Local workspace

Named projects in IndexedDB · Local only — never synced to our servers. Worksp

Open manager

Batch workspace

Format multiple files locally in one run.

Action:
text
Formatted Outputtext

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

  1. 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.
  2. 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.
  3. If the text is a JWT segment or came from a URL, switch to URL-safe mode, which expects no padding.
  4. 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 padding is 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