Base64URL Encoding Guide: The Base64 That Fits in a Link
In standard Base64, the plus and slash characters have meaning inside URLs, so a token pasted into a link gets mangled. Base64URL swaps them out; the underlying algorithm is unchanged.
Open the tool：Base64URL Encoder
When nothing else will do
Put binary or JSON into a query parameter, a path segment, a filename, or OAuth's state and PKCE verifier, and you need the URL-safe alphabet. Otherwise a plus arrives as a space and a slash is treated as a path separator, and the data is broken before it reaches the server.
JWT is the best-known case: header and payload are Base64URL-encoded JSON joined by dots, and the signature uses the same alphabet, so the token can travel in an Authorization header or a URL.
- JWT header, payload, and signature
- OAuth state and PKCE code verifier
- Binary data in URL parameters, paths, and filenames
- Short payloads in webhook callbacks
Three substitutions, no shortcuts
Encode the UTF-8 bytes with Base64, then replace plus with minus, slash with underscore, and strip every trailing equals sign. Doing it in another order, or replacing only some characters, produces something that will not decode. The padding goes because it needs escaping in URLs too.
Size grows to roughly four thirds, which is Base64's fixed overhead rather than anything the tool adds. The result contains only letters, digits, minus, and underscore, so it can sit in a URL without another round of percent-encoding.
- Alphabet: A–Z a–z 0–9 - _
- No trailing equals sign; restore it when decoding
- About 1.33 times the original size
Boundary: reversible and completely public
Base64URL is not encryption. There is no key, and anyone can reverse it. A JWT payload is encoded, not encrypted, so putting roles, internal IDs, or email addresses in it is effectively publishing them.
The signature proves integrity — a change is detectable — but it hides nothing. Use JWE or encrypt the payload when you need confidentiality; use signatures when you need tamper evidence. They solve different problems.
- No key; anyone can reverse it
- JWT payloads are readable, so keep secrets out
- Signatures cover integrity, encryption covers secrecy
FAQ
How is it different from normal Base64?
Exactly three things: plus becomes minus, slash becomes underscore, and trailing padding is removed. Decoding reverses the substitutions and restores padding. The payload is identical; pick based on whether the destination is URL-safe.
Why drop the padding?
Padding carries no data, but an equals sign needs escaping in URLs and tends to break when links are copied or concatenated. The decoder can infer the missing padding from the length, so the round trip stays lossless.
Is a JWT payload secure?
No. It is only Base64URL-encoded, so anyone holding the token can read every field. The signature proves it was not modified; it does not keep it secret. Do not put sensitive data there.
Related tool：Base64URL Encoder