Developer Tools
JWT Decoder
Inspect JWT header, payload, and time claims locally.
JWT Decoder tool
Loading tool…
Jump to a section
About This Tool
A JSON Web Token (JWT) commonly contains three dot-separated Base64URL segments: a header, a payload, and a signature. This decoder lets developers inspect the JSON stored in the first two segments without sending the token to a server. It also interprets standard iat, nbf, and exp NumericDate claims when present. Decoding is only inspection: a readable token is not automatically valid, trusted, or correctly signed.
How To Use It
- Paste a three-segment JWT into the input. Avoid using production credentials when a disposable test token will do.
- Review the decoded header for metadata such as alg and typ, and inspect the payload for application claims.
- If iat, nbf, or exp are numeric, the tool shows them as dates using your device locale and compares exp with the current device time.
- Treat the signature as unverified. Use your application's trusted JWT library and expected key/algorithm to verify authenticity before relying on claims.
Examples
Inspect an API test token
A developer can paste a test JWT to read claims such as sub, aud, scope, or role while debugging an authentication flow.
Check an expiration timestamp
If the payload contains exp: 1893456000, the decoder interprets the NumericDate as a date and reports whether that instant is already past according to the current device clock.
Understand URL-safe encoding
JWT segments use Base64URL, which replaces characters that are awkward in URLs and commonly omits padding. The decoder normalizes that representation before reading UTF-8 JSON.
Useful Notes
JWT structure
Compact JWTs normally have header.payload.signature. The header describes token metadata, the payload carries claims, and the signature or authentication data is used by a verifier to detect unauthorized changes.
Decoding is not verification
Header and payload segments are encoded, not encrypted by default. Anyone holding a typical signed JWT can decode them. Trust requires cryptographic verification using the expected algorithm and trusted key plus application checks for claims such as issuer and audience.
Standard time claims
JWT NumericDate values are seconds since 1970-01-01T00:00:00Z. iat means issued at, nbf means not before, and exp means expiration time. This tool converts numeric values to dates but does not decide whether your application's clock skew or claim policy is acceptable.
Privacy and sensitive tokens
The decoder performs parsing in the browser and does not need a network request for the token. Even so, access tokens can be credentials. Prefer synthetic or expired test tokens for debugging and do not paste secrets into places you do not trust.
Malformed and encrypted tokens
The tool expects a three-part token whose header and payload decode to JSON objects, as required for a JOSE header and JWT claims set. Other compact formats, including five-part JWE encrypted tokens, are intentionally not decrypted or interpreted as ordinary signed JWTs.
FAQ
Does decoding a JWT prove it is valid?
No. Decoding only reveals encoded contents. A modified or forged token can still decode perfectly. Signature verification and application-specific claim validation are separate steps.
Why can I read JWT data without a secret key?
Most signed JWT payloads are Base64URL encoded rather than encrypted. The signature protects integrity and authenticity when verified; it does not hide the payload.
Does this tool verify HS256, RS256, or other algorithms?
No. It deliberately does not accept keys or perform signature verification. Verify tokens inside your application with a maintained JWT library, a trusted key, and an explicit expected algorithm.
Why does my token have five segments?
A five-part compact token is commonly a JWE, which is an encrypted format. This decoder handles the usual three-part JWT/JWS inspection workflow and does not decrypt JWE content.