Base64URL Encoder / Decoder

What this tool is used for

• Reading the header or payload segment of a JWT pulled from a request, each of which is Base64URL rather than standard Base64.
• Producing a token or nonce that survives being pasted into a query string with no further percent-encoding.
• Converting a standard Base64 blob into the URL-safe alphabet before it goes into a path segment.
• Decoding the `state` parameter from an OAuth callback to see exactly what the client round-tripped.
• Checking a signature segment is the expected length before concluding the signing key is wrong.

Frequently Asked Questions

How does Base64URL differ from Base64?

Two characters change: + becomes - and / becomes _. Padding = is usually omitted. Everything else is identical, so the two decode to the same bytes once you translate the alphabet back.

Why is the standard alphabet unsafe in URLs?

Because + means a space in query strings when form-encoded, and / is the path separator. A standard Base64 value pasted into a URL is silently corrupted or splits the path — which is exactly the bug RFC 4648 §5 defines this variant to prevent.

Where will I encounter it?

JWTs use it for all three segments, so a token's header and payload are Base64URL and can be decoded without the key. It also appears in WebAuthn credential IDs, OAuth PKCE challenges and data URIs.

Why is the padding dropped?

Because = is itself reserved in query strings. The length is recoverable without it — the byte count follows from the character count — so padding is redundant. Some decoders still require it, which is a common interop bug.

Is this encryption?

No, and treating it as such is a real security mistake. Base64URL is a reversible encoding with no key: anyone can decode it instantly. A JWT payload is readable by anybody holding the token.

Can I decode a Base64URL string with a standard decoder?

Only after substituting `-` back to `+` and `_` to `/`, and restoring padding to a multiple of four. Many decoders now accept both alphabets, but relying on that is how a string decodes on one platform and fails on another.

How much does encoding inflate the data?

By a third — every three bytes become four characters. That applies to both alphabets, so a JWT's size is roughly 133% of its JSON, before the signature. It is why large payloads do not belong in a token.

Is the encoding canonical?

Not quite. The final character of a partial group has unused bits that a strict encoder sets to zero, but many decoders ignore them — so two different strings can decode to the same bytes. That matters wherever a token is compared as text.

Common errors and gotchas

• Feeding a Base64URL string to a standard decoder. The `-` and `_` characters are the entire point of the variant and exactly what the standard alphabet rejects.
• Adding padding back in the wrong quantity. Length modulo four decides it, and a single leftover character is never valid.
• Assuming a JWT is encrypted because it is encoded. Both the header and the payload decode straight back to readable JSON.
• Percent-encoding a Base64URL value on top of the encoding. Harmless in transit, but it breaks any byte-for-byte comparison.
• Trying to read all three JWT segments as text. The signature is raw bytes and will not decode to anything printable.