Base64 groups source bytes into 24-bit blocks and publishes four six-bit symbols. The final block may contain only eight or sixteen source bits. Padding marks the missing source bytes in a padded profile, while unused low bits inside the last real symbol must be zero. RFC 4648 calls this zero-bit rule necessary for a canonical encoding. Without it, several spellings can decode to the same byte sequence and make string comparison or signature inputs unreliable.
One or two source bytes shape the ending
One remaining byte provides eight bits. It needs two Base64 symbols, four unused low bits in the second symbol and two equals signs in padded form. Two remaining bytes provide sixteen bits. They need three symbols, two unused low bits in the third symbol and one equals sign. Three bytes need four symbols and no padding. An unpadded profile removes only the equals signs; it does not change the zero-bit requirement.
AA== is canonical; AB== is not
Both strings may be accepted by permissive software as the single zero byte because the non-zero low bits in B are discarded while assembling eight output bits. Canonical RFC 4648 encoding requires those four unused bits to be zero, making A the only valid second symbol. Base64Lens reports NON_CANONICAL_BITS for AB== and for the equivalent unpadded AB. This rejects ambiguous spelling before output is shown.
Strict errors make integration differences visible
Whitespace, internal equals signs, more than two padding characters, a padded length outside complete quartets and an unpadded length congruent to one modulo four are separate failures. Base64Lens does not strip line wrapping or repair omitted padding because those choices belong to MIME or another surrounding format. Match the tool settings to the producer specification, then compare canonical output with the receiving library using reviewed non-secret fixtures.