Free tool · No signup
JWT Decoder & Inspector
Paste a JSON Web Token to read its claims, check its expiry and verify its signature, without it leaving your browser.
Runs only in your browser. Your token and key are never sent to a server, saved or added to the URL.
Paste a token to see its header, claims and expiry.
Client side only
A JWT is a credential, so this decoder never sends one anywhere. Decoding, the checks and signature verification run in your browser using the built-in Web Crypto API. Nothing you paste is sent to a server, saved in browser storage or added to the URL, and the tool keeps working with your network turned off once the page has loaded.
What's inside a JWT
A JSON Web Token (RFC 7519) is three base64url-encoded parts separated by dots:
- Header: how the token is signed (
alg), its type (typ) and often which key signed it (kid). - Payload: the claims. Registered ones include who issued it (
iss), who it's about (sub), who it's for (aud) and when it expires (exp). Everything else is a custom claim, such as roles or an email address. - Signature: computed over the header and payload with a secret (HS256) or a private key (RS256, ES256, EdDSA). Change one character of the payload and the signature no longer matches.
The header and payload are encoded, not encrypted. Anyone holding the token can read them, which is why the decoder warns if a claim looks like a password or API key.
What the inspector checks
- Expiry and timing.
exp,nbfandiatare shown as dates in your time zone and UTC, with how long until or since each one. Expired, not-yet-valid and future-issued tokens are flagged, as are times written in milliseconds instead of seconds. - A missing
exp. A token without one never expires. If it leaks, it works until the signing key changes. - Long lifetimes. An access token valid for days is a bigger risk if stolen. Keep access tokens to minutes or an hour and use refresh tokens for longer sessions.
alg: none. An unsigned token. Libraries that once accepted it let anyone forge tokens; your verifier should only accept the algorithms you actually use.- Untrusted key headers.
jku,x5uand an embeddedjwktell the verifier where to find a key. A verifier that follows them can be handed an attacker's key, so they're flagged.
Verifying the signature
For HS256, HS384 and HS512, enter the shared secret. If it's shorter than the hash (32 bytes for HS256), the tool warns you: a short secret can be guessed offline from any token it signed. For RS, PS, ES and EdDSA tokens, paste the public key as PEM, a JWK or a whole JWKS. Identity providers such as Auth0, Okta, Cognito and Firebase publish theirs at a JWKS URL, often /.well-known/jwks.json; the tool picks the key whose kid matches the token.
A valid signature proves who issued the token, not that your app should accept it. In your server, use a maintained library (such as jose for JavaScript or PyJWT for Python), pin the allowed algorithms, and check exp, nbf, iss and aud on every request.
Where to keep tokens in a browser
A token in localStorage can be read by any script that runs on the page, so one XSS bug exposes it. An HttpOnly, Secure, SameSite cookie keeps it out of reach of JavaScript, at the cost of needing CSRF protection for cross-site requests. For most web apps, the cookie is the safer default. If you're building sign-in for a site or app, see what I build, or send me what you have for a review.
By Muhammad Saif · Updated
Questions, answered.
Is my token sent to a server?
No. The decoder is client side only: decoding, the expiry checks and signature verification all run in your browser, with JavaScript and the browser's built-in Web Crypto API. The token, secret and key are never sent to a server, saved in browser storage or put in the URL, and there's no share link for that reason. You can confirm it in your browser's developer tools: pasting a token makes no network requests.
Is it safe to paste a production token?
The token doesn't leave your browser, but a live token is still a credential: anyone who gets it can use it until it expires. Prefer an expired or test token where you can, and don't paste tokens into tools that send them to a server. Never paste a private key anywhere; this tool refuses one and asks for the public key instead.
Does decoding a JWT verify it?
No. The header and payload are only base64url-encoded, so anyone can read them, and anyone can write a token with any claims. Only a signature check with the right secret or public key proves the token came from the issuer and wasn't changed. Your server must verify the signature, then check exp, nbf, iss and aud, before trusting any claim.
Is the JWT payload encrypted?
No. A signed JWT (JWS) is readable by anyone who holds it, so never put passwords, API keys or personal data you wouldn't show the user in it. Encrypted JWTs (JWE) have five parts instead of three and need the recipient's private key; this tool shows their header only.
Which algorithms and key formats can it verify?
HS256, HS384 and HS512 with a shared secret, as plain text or base64. RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA (Ed25519) with a public key as PEM (-----BEGIN PUBLIC KEY-----), a JWK or a JWKS; from a key set, the key matching the token's kid is used. To check a token from your identity provider, open its JWKS URL (often /.well-known/jwks.json) and paste the JSON.
Why does my token show as expired when it isn't?
Usually a clock or unit problem. exp is in seconds since 1970 UTC, not milliseconds; a millisecond value is flagged. Times are shown in your local time zone and in UTC, measured against this device's clock, so a device clock that's off by a few minutes will show tokens expiring early or late. Most servers allow 30 to 60 seconds of clock skew.