Both variants turn the same bytes into six-bit symbols, but they do not publish the same text for every byte sequence. Standard Base64 uses plus and slash. Base64url replaces those two symbols with dash and underscore so the encoded value fits URL and filename contexts more easily. Record the expected variant before decoding: guessing from a string that contains only shared alphanumeric symbols cannot prove which contract produced it.

Two symbols define the alphabet difference

RFC 4648 standard Base64 maps sextet 62 to plus and 63 to slash. Base64url maps the same values to dash and underscore. For the UTF-8 text Hello>?, standard padded output is SGVsbG8+Pw== while unpadded base64url is SGVsbG8-Pw. Every other symbol represents the same six-bit value. Base64Lens rejects a character from the other alphabet instead of silently translating it, because an explicit failure exposes a mismatched integration contract.

Padding is a separate explicit choice

The equals sign is not one of the 64 data symbols. It fills the final four-character quantum when one or two source bytes remain. Standard protocol profiles often require canonical padding, while base64url profiles often omit it when the data length is known. Those conventions come from the surrounding specification, not from visual appearance. Base64Lens therefore makes padded and unpadded forms explicit and never adds or removes equals signs during decoding.

Base64URL is not a token validator

JWT and other security formats may use unpadded base64url for individual fields, but decoding those fields does not verify a signature, issuer, audience, expiry or trust chain. Base64Lens deliberately accepts only one text value and returns UTF-8 text. It does not split tokens, interpret claims or certify decoded content. Use the receiving protocol and its trusted library for validation after confirming the exact alphabet and padding contract.