JWT Decoder — Inspect, Verify & Check Expiry
Decode a JWT's header and payload, read its expiry in UTC and Asia/Karachi, and optionally verify its signature with WebCrypto — the token never leaves your browser.
Runs in your browser; nothing is uploaded.
Tokens never leave your browser — decoding and verification both run locally.
Paste a JWT to see its header, payload and claim times (Ctrl/⌘+Enter decodes immediately).
How to use it
How to decode a JWT
Paste a JWT into the box. It decodes automatically — the header and payload appear as formatted JSON as soon as you stop typing.
Check the alg badge: if it says
none, the token is unsigned and anyone could have created it — that's flagged, not hidden.If the payload has
iat,expornbfclaims, their times are shown in both UTC and Asia/Karachi, along with a plain-English status like "expires in 2 hours" or "expired 8 years ago".To check a signature, use Verify signature: for HS256/384/512 tokens, paste the shared secret; for RS256/384/512 or ES256/384/512 tokens, paste the issuer's PEM public key (
-----BEGIN PUBLIC KEY-----…). Both run through your browser's built-in WebCrypto — no external library, no network call.A token with 5 parts instead of 3 is a JWE (an encrypted token, not a signed one) and isn't decoded here, since JWE payloads are ciphertext by design.
The token, any secret, and any public key you paste are only ever read by JavaScript already running in this page — decoding this way can't send them anywhere, by design.
Frequently asked questions
Is it safe to paste a production access token into a JWT decoder?
This tool never makes a network request — decoding and verification both run with JavaScript already loaded in your browser. That said, treat any tool the same way: prefer a throwaway or expired token when you're just exploring the format, since a JWT's claims (and its signature, if you have the key) are fully readable once decoded.
Why does it say the algorithm is "none" and warn about it?
"alg": "none" means the token has an empty signature and isn't cryptographically protected at all — anyone can construct one with any claims they like. Several real-world JWT vulnerabilities have come from libraries that accepted an alg:none token as if it were verified; this tool flags it instead of treating it as valid.
What's the difference between exp, iat and nbf?
iat (issued at) is when the token was created; exp (expiration) is when it stops being valid; nbf (not before) is when it starts being valid — a token can be issued now but deliberately not usable until a later time. All three are Unix timestamps (seconds since epoch), which is why this tool converts them to readable dates.
Why 3 parts, and what's a 5-part token?
A signed JWT (JWS) always has exactly 3 base64url segments — header, payload, signature — separated by dots. A token with 5 segments is a JWE (JSON Web Encryption): its payload is encrypted ciphertext, not a readable JSON object, so there's nothing to "decode" without the decryption key.
Can this tool verify RS256 or ES256 tokens?
Yes, if you have the issuer's public key in PEM format. RSA (RS256/384/512) verification uses WebCrypto's RSASSA-PKCS1-v1_5, and ECDSA (ES256/384/512) uses WebCrypto's ECDSA with the matching named curve — both entirely client-side, without any third-party JWT library.