Paste a JSON Web Token into this JWT decoder to decode its header and payload into readable JSON, see when it was issued and when it expires, and get a warning if it is unsigned. Add the shared secret or the public key (PEM, certificate or JWK) to verify the signature. Decoding and verification happen locally in your browser; even so, do not paste live production tokens into sites you do not trust.
Loading the tool… It runs in your browser and needs JavaScript.
Table of Contents
How to use the decoder
Paste the token; a leading Bearer from an Authorization header is ignored. The header and payload appear as formatted JSON, and the claims table turns exp, iat, nbf and auth_time into UTC and local dates with a plain “expired 2 hours ago” or “valid for 3 days more” summary. Encrypted tokens (JWE, five parts) can only show their header.
What is inside a JWT
A signed JWT (RFC 7519) is three Base64url parts joined by dots: the header, the payload and the signature. The first two are only encoded, not encrypted, so anyone holding the token can read them. Never put secrets in a JWT payload. You can decode one in a shell too:
cut -d. -f2 <<< "$TOKEN" | tr '_-' '/+' | base64 -d 2>/dev/null | jq .
# base64 may complain about missing = padding; the JSON is usually still printedVerifying the signature
- HS256, HS384, HS512: paste the shared secret. Tick the Base64 option if your framework stores the secret Base64-encoded.
- RS256/384/512 and PS256/384/512: paste the RSA public key as
-----BEGIN PUBLIC KEY-----,BEGIN RSA PUBLIC KEYor an X.509 certificate. - ES256, ES384, ES512: an EC public key on P-256, P-384 or P-521.
- EdDSA: an Ed25519 public key, in browsers that support it in Web Crypto.
- JWK or JWKS: paste the JSON from your identity provider’s
jwks_uri; the key whosekidmatches the token header is used.
“Invalid signature” means either the key is wrong or the header or payload were changed after signing. If you paste a private key the tool refuses it: treat that key as exposed and rotate it.
Common problems
- alg “none”: the token has no signature. Servers must reject it; accepting it lets anyone forge tokens.
- Expired too early:
expis in seconds, not milliseconds. A value with 13 digits is a bug in the issuer. Clock skew between servers also matters, so keep NTP running (timedatectl status). - Not valid yet:
nbfis in the future, usually because the issuing server’s clock is ahead. - Wrong key type: RS256 tokens need a public key, not the client secret.
Privacy
This page sends nothing anywhere: the token and keys stay in your browser tab. A valid access token still works like a password until it expires, so prefer testing with tokens from a development system.
JWT Decoder at a glance
Related tools: Base64 Encoder and Decoder · Hash Generator (MD5, SHA-1, SHA-256, SHA-512) · JSON Formatter and Validator · Unix Timestamp Converter.
Official documentation (checked 9 October 2026): RFC 7519: JSON Web Token (JWT) · RFC 7515: JSON Web Signature (JWS) · RFC 7518: JSON Web Algorithms (JWA) · MDN: SubtleCrypto.verify()
Frequently asked questions
Does decoding a JWT prove it is genuine?
No. Anyone can create a token with any payload. Only a successful signature check with the right key shows it was issued by the key holder and not altered.
Why are exp and iat plain numbers?
They are NumericDate values: seconds since 1 January 1970 UTC. The claims table converts them to dates for you.
Can I decode an encrypted JWE token?
Only its header. The payload is encrypted and needs the recipient’s private key, which you should never paste into a web page.