JWT decoder

How to use

1. Paste the token into the JWT token field, exactly as you got it: with a leading Bearer, in quotes, split across several lines or even inside a JSON response, a cookie or a URL (the token is found in the text).
2. The token is colored by part (header, payload and signature), and next to it you get the decoded header and payload as formatted JSON.
3. In the claims list, each field comes with a short explanation. Dates such as exp, iat and nbf are shown in your time zone, in UTC and as relative time ("expires in 2 hours").
4. To check whether an HS256, HS384 or HS512 token is authentic, type the secret under Verify signature. No token at hand? Tap Sample: the sample's secret is shown right below the field.

What a JWT is

A JWT (JSON Web Token) is a compact format for passing information between systems, widely used for logins and APIs. It has three parts separated by dots:

• Header: which algorithm signed the token (alg) and sometimes which key (kid).
• Payload: the information itself, called claims: who the user is, which system the token is for, until when it's valid.
• Signature: a code computed over the first two parts. Change a single character of the payload and the signature no longer matches.

The header and payload are JSON encoded as base64url, a base64 variant that swaps + and / for - and _ and drops the trailing =, so it fits in URLs and HTTP headers. That's why every JWT starts with eyJ: it's the encoded {" of the JSON.

The most common claims

• iss (issuer): who generated the token, such as the login server.
• sub (subject): who the token is about, usually the user ID.
• aud (audience): which app or API it was issued for.
• exp (expiration), nbf (not before) and iat (issued at): dates in seconds since January 1, 1970, UTC (so-called Unix time). A token whose exp is in the past must no longer be accepted; one whose nbf is in the future isn't valid yet.

Identity providers add others, such as email, roles, scope and sid. Fields the tool doesn't recognize are listed as custom claims.

Decoding isn't verifying

Anyone can read a JWT: the payload isn't encrypted, only encoded. The tool shows what's written, but that doesn't prove the token is legitimate. The signature is what guarantees where it came from, and it's the server that decides whether to accept the token after verifying it.

Hence the most important rule: never put secrets in the payload, such as passwords, ID numbers or API keys. If the data must stay hidden, the right format is JWE (an encrypted token with five parts), which the tool recognizes and explains.

HS256 or RS256?

• HS256 (and HS384/HS512) uses a shared secret: the same secret signs and verifies. It's simple, but every service that verifies tokens could also issue them. This is the case this page verifies.
• RS256 (and ES256, PS256, EdDSA) uses a key pair: the private key, kept only by the issuer, signs; the public key, which can be shared freely, verifies. It's the standard for login providers such as Google, Microsoft and Auth0. To verify these tokens, use your server's JWT library with the provider's public key.

Common pitfalls

• alg: none: a token without a signature. Servers must never accept it; some old libraries did, and it became a classic security flaw.
• Milliseconds instead of seconds: using JavaScript's Date.now() makes exp a thousand times larger, so the token "lasts" for thousands of years. The tool warns you when a number looks like milliseconds.
• Out-of-sync clocks: if the issuing server's clock runs ahead, the token may arrive with iat or nbf in the future and be rejected. Libraries usually allow a few seconds of leeway.
• No exp, or a very long lifetime: if the token leaks, it keeps working. Prefer short-lived access tokens (minutes) renewed with a refresh token.
• Storing the token in localStorage: any script running on the page (including one injected through an XSS flaw) can read it. HttpOnly and Secure cookies reduce that risk.

Privacy

Everything happens in your browser: the token and the secret are never sent to a server, aren't stored and disappear when you close the page. Verification uses the browser's built-in cryptography (Web Crypto), which requires a secure (HTTPS) page. Still, treat production tokens like passwords: once you're done testing, revoke them or let them expire.