JWT Decoder

How to decode a JSON Web Token?

Decoding a JWT takes a single paste — there is nothing to configure:

• Copy the token from your browser dev tools, an API response, or your application logs. You can paste it with or without the leading 'Bearer ' prefix.
• Paste it into the input box. The token is decoded automatically as you type — no button to press.
• The header (algorithm and token type) and the payload (the claims) appear side by side as formatted, highlighted JSON.
• The signature part is shown separately, exactly as it appears in the token. It stays base64url-encoded because signatures are binary data, not text.

How to check if a token is expired?

The tool reads the registered time claims for you:

• The status line under the output tells you whether the token is valid, expired, or not yet active, and how long is left.
• The 'Registered Claims' panel converts 'exp', 'iat' and 'nbf' from Unix timestamps into readable UTC dates with a relative time.
• Tokens without an 'exp' claim are reported as having no expiry — a red flag for production tokens.

Reading the decoded output

Each section maps to a part of the token:

• Header — usually contains 'alg' (HS256, RS256, ES256...) and 'typ'. Optionally 'kid' tells the server which key to verify with.
• Payload — your claims: standard ones like iss, sub, aud, exp, nbf, iat, jti plus any custom application claims.
• Signature — produced by signing 'header.payload' with a secret key (HMAC) or private key (RSA/ECDSA). It is not encrypted and not readable as text.

What is a JSON Web Token?

A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe way to represent claims securely between two parties. A JWT is a string made of three base64url-encoded parts separated by dots. The first part is the header, which describes how the token is signed. The second is the payload, a JSON object holding the claims — statements about the user, the issuer, expiry, and permissions. The third is the signature, computed over the first two parts with a secret or private key. A key property: JWTs are signed, not encrypted. Anyone holding the token can read the header and payload with no key at all, which is exactly why decoders like this one work. The signature only guarantees integrity and authenticity — that the content came from the issuer and has not been altered. This means you should never put sensitive data such as passwords, credit card numbers, national IDs, or internal secrets inside a JWT payload, because every recipient and every proxy that touches the token can read it.

Registered claims and what they mean

The JWT specification defines a set of optional but conventional claims that servers and libraries understand automatically. 'iss' (issuer) identifies the party that created the token, typically your auth server URL. 'sub' (subject) identifies the principal the token is about — usually a user ID. 'aud' (audience) states who the token is intended for, and a compliant API must reject a token whose audience does not match it. 'exp' (expiration time) is a Unix timestamp after which the token must be rejected. 'nbf' (not before) is the earliest moment the token may be accepted, useful for tokens issued slightly ahead of time. 'iat' (issued at) records when the token was created and lets you enforce maximum session ages. 'jti' (JWT ID) is a unique identifier used to prevent replay attacks by blacklisting a token once it has been used. All time claims are expressed as NumericDate values — seconds since the Unix epoch, UTC — not milliseconds, which is a very common implementation mistake, since JavaScript's Date.now() returns milliseconds.

JWT vs opaque session tokens

Traditional session authentication stores a random opaque session ID in a cookie and keeps the session state in a database or Redis. Every request requires a lookup. A JWT takes the opposite approach: all necessary state travels inside the token, so any service holding the verification key can validate a request without a database round trip. This statelessness is what makes JWTs popular for microservices, mobile apps, and cross-domain APIs. The trade-off is revocation. Because a JWT is self-contained and valid until it expires, you cannot invalidate it centrally without extra machinery such as short lifetimes plus refresh tokens, a jti blacklist, or rotating signing keys. The practical pattern is a short-lived access token (5–15 minutes) sent in the Authorization header and a long-lived refresh token stored in an HttpOnly, Secure, SameSite cookie. Decoding a token client-side helps you debug exactly those lifetimes when authentication mysteriously starts failing.

Common JWT mistakes to avoid

The 'alg: none' attack: an early generation of JWT libraries accepted unsigned tokens when the header declared 'alg: none', letting an attacker forge any payload. Always whitelist the algorithms you accept on the server instead of trusting the header. Confusing decoding with verification: this tool decodes — it proves nothing about authenticity. Never treat a decoded payload as trusted on the server; only a signature check performed with your key does that. Mixing up signing algorithms: HS256 uses one shared secret for both signing and verifying, so if an API that normally expects RS256 public keys accepts HS256, an attacker can sign tokens using the public key as an HMAC secret. Clock skew: tokens rejected as 'not yet valid' are often simply issued by a server a few seconds ahead, so allow 30–60 seconds of leeway. Oversized payloads: JWTs are sent with every request, so keep claims minimal — a large payload bloats every API call. And finally, storing tokens in localStorage: any XSS on the page can read it, so prefer HttpOnly cookies where the architecture allows.