Base64url and padding: why tokens use a different alphabet

Worked example: padding variants

Use this exact sample to isolate the behavior discussed above. Keep the operation and options with the sample when reporting a result; changing the input representation can change what the test demonstrates.

Input or question

UTF-8 text: hi
Standard: aGk=

Expected result or interpretation

Base64url without padding: aGk

A segment can decode successfully and remain untrusted

A token-like value may carry a Base64url-encoded JSON payload with a field such as {"role":"admin"}. Decoding reveals that text; it does not establish that the payload was issued by your service. A user can construct a different encoded payload just as easily. The application must verify the token under its protocol before accepting claims, then apply expiry and authorization rules. Do not change a production token for a public example. Create a synthetic segment with no valid credential value and label it as an inspection exercise. Successful UTF-8 decoding answers a representation question only, even when the result looks like plausible application data.

Identify the variant from the protocol

Both alphabets share letters and digits, so some values look identical under either variant. Base64url maps plus to hyphen and slash to underscore without changing the underlying bits. Use the producer’s specification to decide which alphabet is intended. URL-safe output is helpful where these characters otherwise have transport meanings, but it is not automatically interchangeable with standard Base64 in every API.

Understand padding rather than deleting it

Base64 encodes three bytes as four symbols. A final partial group uses one or two padding characters in standard padded output. Those equals signs are not decoded content. A protocol may allow omission because the original length can be inferred. The tool restores missing padding for structurally valid input, but a stricter consumer may require a specific canonical spelling.

Decode structured tokens by segment

A dot-separated token may contain several Base64url segments. Decode an individual segment rather than the entire dotted value. Reading a header or payload does not verify a signature, establish expiration or authorize any operation. All decoded claims remain untrusted until the protocol’s verifier checks them. This text tool deliberately does not label decoded token content as verified.

Test transport separately

Standard Base64 plus characters can be interpreted as spaces by a form-style query parser. Percent-encode the component or use Base64url if the protocol specifies it. Include fixtures with padding and alphabet-sensitive characters in an integration test; an all-letter example may not expose a wrong variant. Trace the request value through the actual encoder and receiver rather than repairing arbitrary whitespace afterward.

Separate parser convenience from canonical format

A decoder may accept several spellings that represent the same bytes. That does not mean a protocol accepts all of them or signs them interchangeably. Keep canonical output rules with the data format: alphabet, padding, whitespace and segment boundaries. Our URL-safe output omits padding, while standard output uses it. The text decoder accepts structurally valid unpadded input as a convenience for inspection.

When a token format requires a specific spelling, verify that exact spelling before treating successful decoding as format compliance. An invalid signature cannot be repaired by decoding and re-encoding a segment unless the protocol explicitly defines that operation. Re-encoding may change the bytes of the signed representation. Use short synthetic examples for debugging and never include a live bearer token in a report. For integration tests, include all three input-length remainders modulo three to cover no padding, one equals sign and two equals signs in standard output. Include an alphabet-sensitive binary test in the application test suite when possible, because ordinary words may not produce plus or slash. The browser tool is text-focused, so it should not be stretched into a general binary fixture editor merely to cover that separate requirement.

Keep an invalid-length fixture too. A single Base64 symbol cannot represent a complete byte. A decoder should reject that case rather than invent missing content merely by adding padding.

Verification cases

• h: Standard output uses two padding characters.
• hi: Standard output uses one padding character.
• Three UTF-8 bytes: A complete group needs no padding.

Decision reference

Before you use the result

1. Select the variant from documentation.
2. Record whether padding is required.
3. Do not equate decoding with verification.
4. Check query handling for literal plus characters.

Continue the workflow

Encode Unicode text as Base64 without breaking emoji addresses fix base64 encoding of non-ascii text. Why a plus sign becomes a space in a query string addresses debug plus signs in query/form data.