How to Handle Base64 Padding

Why Base64 Needs Padding

Base64 encodes 3-byte groups as 4 characters. When the input length isn't divisible by 3, the final group has 1 or 2 bytes remaining. One remaining byte encodes as 2 characters plus two = signs. Two remaining bytes encode as 3 characters plus one = sign. The = padding signals how many bytes were in the final group.

When Padding Can Be Omitted

Padding is technically redundant — the total length of the encoded string implies how many = signs are needed. Many protocols omit trailing padding: JWT tokens, URL-safe Base64, and many API tokens drop trailing = characters. Decoders that handle padless Base64 re-add the padding before decoding.

Padding Bugs and Fixes

Common Base64 bugs: adding extra padding when there's already padding, expecting padding when the source doesn't produce it. The fix is always to normalize to padded form before decoding: add missing = characters until the string length is divisible by 4.

Padding in Different Contexts

Email MIME Base64 requires padding per the spec. JWT tokens omit padding. URL-safe Base64 typically omits padding. Standard Base64 for data URLs includes padding. When implementing code that works across these contexts, build a normalizer that accepts both and adds padding as needed.