Base64URL and JWT: Decode Payloads Without Trusting Them
JWTs use Base64URL, not plain Base64. Learn what you can read, what you must verify, and where padding fits.
A JWT is three URL-safe parts
A common signed JWT has three dot-separated parts: header, payload, and signature. RFC 7519 defines JWT as a compact, URL-safe way to carry claims. RFC 7515 defines the Base64URL encoding used by JWS compact serialization.
Base64URL changes the alphabet
Base64URL keeps the same 6-bit idea as Base64, but it changes two characters: + becomes - and / becomes _. JWT also omits trailing = padding. This choice lets the token travel in headers, URLs, and form values with less escaping.
Decoding is not verification
You can decode the header and payload to inspect JSON claims such as iss, sub, aud, exp, or scope. That action only reads text. It does not prove the issuer, the audience, the expiry, or the signature. A server must verify the signature or MAC with the correct key and algorithm before it trusts any claim.
Watch for the alg trap
The header names the algorithm, but the application must decide which algorithms it accepts. Treat an unexpected alg value as a validation failure. Do not let a token choose a weaker method for your system.
Use a clear debug flow
Split the token on dots. Decode the first two parts as Base64URL. Add padding from the length rule only for tools that need it. Read the JSON. Then verify the signature with the issuer keys and check issuer, audience, time claims, and application rules.