Decoding JWTs Safely: Decoding Is Not Signature Verification

A JSON Web Token commonly contains three dot-separated segments: header, payload, and signature. The first two are Base64URL-encoded JSON. Anyone who has the token can decode them. That readability is a feature, not proof that the claims are trustworthy.

The JWT Decoder splits the token, decodes the header and payload, and displays fields such as sub, iss, aud, iat, and exp. It does not have a trusted secret or public key, so it does not verify the signature.

Consider a payload containing {"role":"admin"}. A person can create that text and encode it into a token-shaped string. A decoder will display the claim correctly because decoding asks only “what bytes are here?” Verification asks “did a trusted issuer sign these exact bytes with an allowed algorithm?”

Safe validation requires more

• Pin the expected signing algorithm; never accept an algorithm just because the token header requests it.
• Select trusted key material for the expected issuer.
• Verify the cryptographic signature before trusting claims.
• Validate issuer, audience, expiry, not-before time, and any application-specific requirements.
• Handle key rotation, clock skew, token revocation policy, and replay risk in the application.

Do not paste active production credentials into websites unnecessarily. This decoder processes the entered token in the browser, but tokens can still appear in screenshots, clipboard history, extensions, logs, or shoulder surfing. Use a redacted or expired sample whenever possible.

For authorization, use a maintained JWT library in the server or trusted client that owns the security decision. Primary references: RFC 7519 and the OWASP JWT cheat sheet.