Quick answer
A JSON Web Token usually contains Base64URL-encoded header and payload segments plus a signature. Decoding reveals the claims but does not verify the signature. Never trust a token merely because its JSON looks valid, and avoid pasting live credentials into remote tools.
How to do it
- Decode the token locally and inspect the alg, typ, iss, aud, exp, nbf, and sub claims.
- Treat the header and payload as untrusted until a trusted library verifies the signature.
- Check issuer, audience, time claims, allowed algorithms, and key selection in the application.
Decoding is not verification
Anyone can create or modify the first two JWT segments. Verification recomputes or checks the signature with an approved key and algorithm, then applies claim rules. A generic browser decoder has no authority to decide whether your application should accept the token.
JWT content is visible
Base64URL provides transport-safe encoding, not confidentiality. Do not place passwords, private keys, or unnecessary personal data in a JWT. Tokens copied from production may grant access until expiry and should be handled like credentials.
Common mistakes to avoid
- Accepting alg values supplied by an attacker without a policy.
- Ignoring issuer and audience after signature verification.
- Sharing a live bearer token in screenshots or support tickets.
Try the related tool
Use QRFoundry directly in your browser. Tool inputs and uploaded files are processed on your device.
Open JWT Decoder