JWT Decoder
Decode and inspect JWT tokens — header, payload, and signature.
By Syed Mubashir Ali · Last updated
What a JWT can tell you when debugging
A JWT is three base64url-encoded parts separated by dots: a header, a payload and a signature. The header says how it was signed, such as HS256 or RS256. The payload holds the claims: who the token is about (sub), who issued it (iss), who it's for (aud), when it was issued (iat) and when it expires (exp), plus whatever roles or scopes the app adds. The decoder shows both as formatted JSON and turns iat and exp into readable dates, with a badge if the token has expired.
That answers most 'why is this request unauthorised?' questions: the token has expired, it was issued for a different audience, or a role the API expects isn't in it. Remember that decoding isn't verifying. Anyone can read a JWT, and only someone with the key can tell whether it's genuine, so never put secrets in a payload. Paste the secret or public key into the verify box to check a token's signature. Everything happens in your browser, but use test tokens rather than live ones where you can.
Reading the standard claims
Seven claims are registered in the JWT specification and appear in most tokens. 'iss' identifies who created the token: typically your identity provider's URL. 'sub' is the subject, usually a user ID. 'aud' names the intended recipient; an API should reject tokens whose audience isn't itself. 'exp' and 'iat' are expiry and issued-at times as seconds since 1970. 'nbf' (not before) marks when the token becomes valid, and 'jti' is a unique ID useful for revocation lists.
Beyond these, providers add custom claims: roles, permissions, organisation IDs, subscription tiers. There's no central registry for custom claim names, so check your provider's docs when something looks unfamiliar. Short, namespaced names (like 'https://example.com/roles') avoid collisions between providers.
How to Use JWT Decoder
- 1Paste your JWT into the input field, or press 'Try a sample' to see a signed example.
- 2The header and payload are decoded and shown as formatted JSON as you type, with the issued, not-before and expiry times in your own time zone.
- 3Check the badges: Expired or Not expired, and Not valid yet if the nbf time hasn't arrived. A token with "alg": "none" gets a warning, because it has no signature at all.
- 4To check the signature, paste the shared secret (HS256, HS384, HS512; tick 'Secret is Base64-encoded' if it is) or the issuer's public key in PEM format (RS, PS and ES algorithms). It says 'Signature verified' or 'Invalid signature'.
- 5Inspect the claims (sub, iss, aud, iat, exp) to understand what the token asserts. Prefer test tokens to live production ones.
Frequently Asked Questions
Can it verify the signature?
Yes, if you give it the key. For HS256, HS384 and HS512 paste the shared secret; for RS, PS and ES tokens paste the issuer's public key (-----BEGIN PUBLIC KEY-----). The check runs in your browser with the Web Crypto API, so the key isn't sent anywhere. Even so, avoid pasting a live production secret into any website; a public key is safe to share by design.
What does the alg: none warning mean?
The token's header says it isn't signed, so anyone could have written it. Some old libraries accepted such tokens, which let attackers forge them; a server should always reject them. The decoder flags it so it's not missed.
What is a JWT?
A JSON Web Token is a compact, URL-safe way to represent claims between two parties. It consists of three base64url-encoded parts: header, payload, and signature, separated by dots.
Is it safe to paste my JWT here?
All decoding happens locally in your browser: nothing is sent to any server. However, JWTs may contain sensitive data (user IDs, roles, emails), so use test tokens only.
Can anyone read the data in a JWT?
Yes. The header and payload are only encoded, not encrypted, so anyone who has the token can decode them, exactly as this tool does. The signature stops them being changed, not read. Encrypted tokens (JWE) are a different format.
Why does my token show as expired?
Its exp claim, a time in seconds since 1970, is in the past. The decoder shows that time in your own time zone; if a token expires sooner than you expect, compare the iat and exp dates to see how long it was issued for.
What's the difference between the header and the payload?
The header describes how the token is secured: the signing algorithm (like HS256 or RS256) and the token type. The payload carries the actual claims: who the token is about, who issued it, when it expires, and any custom data like roles or permissions.
Why does decoding work without the secret key?
Because decoding isn't decrypting. The header and payload are base64url-encoded, which is just a text-safe way of writing the JSON: anyone can reverse it. The key is only needed to verify the signature, which proves the token wasn't tampered with. Your server must do that check on every request; the verify box here is for debugging.
What should I do if the payload contains unexpected claims?
Compare against your identity provider's documentation. Extra claims are often fine: providers add things like authentication method or session IDs. Missing claims the API expects (like a role or scope) usually explain authorization failures.
Does it remember what I typed?
Not unless you ask. "Remember recent inputs" is off for this tool because a live token works like a password. Tick it to keep the last five inputs in this browser only (nothing is sent anywhere), with a Recent menu to bring one back and "Clear recent" to forget them.
About JWT Decoder
JWTs are ubiquitous in modern authentication: used by OAuth, OpenID Connect, and countless APIs. Our JWT Decoder lets you inspect the contents of any JWT instantly (the algorithm in the header, the claims in the payload, the expiry status) and check the signature with a secret or public key.
The decoder needs no external library. It handles base64url decoding (which differs from standard base64 in using - and _ instead of + and /), parses the JSON, formats timestamps into human-readable dates, and verifies HS, RS, PS and ES signatures with the browser's built-in Web Crypto API.
When an API returns 401 Unauthorized, the token itself usually holds the answer. Paste it here and check: has it expired? Was it issued for the right audience? Does it contain the role or scope the endpoint requires? These three checks resolve the majority of authentication debugging sessions.
A word of caution that bears repeating: JWT payloads are readable by anyone holding the token. Never put passwords, secrets, or sensitive personal data in claims. The signature guarantees integrity (that nobody altered the token) not confidentiality.