JWT Decoder: Read a Token, Check Its Expiry, Spot Weak Spots

How to use the JWT Decoder: Read a Token, Check Its Expiry, Spot Weak Spots

1. Paste the tokenPaste a JWT into the box. You can paste it as it is, with a leading Bearer, a whole Authorization header, a cookie or URL that contains it, or a JSON response with an access_token field. The page cleans it up and tells you what it did.
2. Read the statusThe colored box at the top says whether the token has expired, is not valid yet, still has time left, or never expires. It also names the algorithm and, when it can tell, the service that issued the token.
3. Go through the checksProblems and warnings come first, each with the reason and the standard it comes from. Open the notes below them for the rest. The checks read only the token, so they cannot say whether it is genuine.
4. Read the claimsThe payload is listed claim by claim with a plain-language meaning. Dates are shown in UTC with how long ago or how far ahead they are. Open the raw JSON if you want to copy it.
5. Check the signatureIf you have the secret or the public key, open the signature check and enter it. The page verifies the signature and tells you whether the token has been changed or was signed with another key.

What is inside a JWT

A signed JWT has three parts separated by dots. The first is the header, a small JSON object that says which algorithm signed the token. The second is the payload, a JSON object of claims, which are statements such as who the token is about and when it expires. The third is the signature, the bytes that let a service check that the first two parts have not been changed.

The header and payload are written in base64url, which turns bytes into letters, digits, hyphens, and underscores so that the token can travel in a URL or an HTTP header. This is encoding, not encryption. Anyone who holds the token can decode it, which is exactly what this page does. An encrypted token, called a JWE, has five parts instead of three, and only its header can be read without the key.

• Header: the algorithm (alg), often the type (typ), and sometimes a key ID (kid) that says which key to verify with.
• Payload: the claims. Seven are registered in RFC 7519: iss, sub, aud, exp, nbf, iat, and jti.
• Signature: not readable text. It only means something to a program that has the right key.

Decoding is not verifying

The most important thing to understand about JWTs is that reading a token proves nothing. An attacker can write a header and a payload in a minute. What makes a real token real is the signature, and only a service that checks it with the right key can trust the claims inside. Code that decodes a token and acts on it without verifying is one of the commonly reported mistakes with JWTs.

Verification has more steps than checking the signature. A service must also fix the algorithms it accepts rather than trusting the header, check that the issuer is one it trusts, check that the audience names itself, and reject a token that has expired or is not yet valid. RFC 8725 lists these as best practices, and the audit on this page checks whether a token even gives a service the information to do them.

• Verify the signature with a key the service already trusts, and never with a key supplied inside the token.
• Accept only the algorithms you expect, so a token cannot choose its own.
• Check iss, aud, exp, and nbf on every token.
• Treat the claims as untrusted input until all of that has passed.

Reading the claims and the dates

A JWT date is a number of seconds since 1 January 1970 UTC, which RFC 7519 calls a NumericDate. The page converts each one, shows it in UTC, and says how long ago or how far ahead it is. The exp claim is the moment on or after which the token must not be accepted, so a token whose exp equals the current second counts as expired. The nbf claim is the earliest moment it may be used, and iat is when it was issued.

RFC 7519 lets a service allow a small leeway, typically a few minutes, for differences between clocks. If a token is rejected as expired or not yet valid by a few seconds, a clock that is slightly off is the usual cause. A value like 1790000000000, with three extra digits, is a date in milliseconds written by mistake. Read as seconds, it lies tens of thousands of years in the future, and the audit flags it.

• iss: who issued the token. sub: who it is about. aud: who it is for.
• exp, nbf, and iat: when it stops being valid, starts being valid, and was made.
• jti: a unique ID for the token, used to detect a token being replayed.
• Anything else is a custom or provider-specific claim, and the page says so rather than guessing.

What the security checks look for

The checks are drawn from RFC 7519 and RFC 8725. They look only at what is inside the token, so they flag signs that a token is risky or badly made. They do not prove that it is safe.

• An unsigned token (alg set to none), or a signature part that is empty. RFC 7519 allows unsecured tokens only where they are protected some other way.
• No expiry, a lifetime of more than a day or a month, or an expiry before the issue time. A JWT cannot be recalled, so the lifetime sets how long a stolen token is useful.
• No audience or no issuer, which leave a service unable to tie the token to itself or to a trusted source (RFC 8725, sections 3.8 and 3.9).
• Dates written as text or in milliseconds.
• Header fields that name or carry a key: jku and x5u, which can lead a careless service to fetch keys from an attacker, and jwk, which supplies a key inside the token.
• A key ID with unusual characters, which can lead to injection if it is used in a database or file lookup.
• Claim names that suggest secrets, such as password or api_key. The payload is readable by anyone who sees the token.
• A signature of the wrong length for its algorithm, including the very common case of an ECDSA signature in DER form instead of the format JWT requires.
• A token longer than a browser cookie or a typical server header can hold.

Tokens from identity providers

Most tokens you meet come from an identity provider that follows OpenID Connect. An ID token tells an application who signed in, and it carries claims such as name, email, nonce, and auth_time. An access token is for an API and typically carries scopes or roles instead. The two are easy to mix up, and sending an ID token to an API as if it were an access token is a classic error. The page makes a careful guess from the claims, and reads a typ of at+jwt as an access token.

Providers add their own claims. Microsoft Entra ID, for example, puts the tenant in tid, a user or app identifier that is the same across applications in oid, the permissions in scp or roles, and the token version in ver. The page recognizes the issuer addresses of the common providers and explains their claims, and it tells you plainly when a claim is custom. Microsoft itself advises that applications should not depend on a claim being present, so check the documentation of your provider for the claims you rely on.

Checking a signature here

Choose the signature check and give the page the key. For tokens signed with a shared secret (HS256, HS384, HS512), enter the secret, as text or as base64url. For tokens signed with a key pair (RS, PS, ES, and EdDSA algorithms), paste the public key as a PEM block, an X.509 certificate, a JWK, or a whole key set from a JWKS address, in which case the page picks the key whose kid matches the token. The checking uses your browser's Web Crypto API.

Two safeguards are built in. First, the page decides which kind of key to accept from the algorithm in the header and refuses a public key for an HMAC token. Without that rule, an attacker could relabel an RSA-signed token as HS256 and sign it with the public key, which many libraries once accepted. Second, it refuses private keys outright, in PEM or JWK form, because verification never needs one and a private key should never be pasted into any web page.

Common JWT errors and what they mean

Most JWT problems turn out to be one of a few causes, and the page names the cause where it can.

• “Token has two parts” or “four parts”: the token was cut off or two were joined. A signed token has three parts, an encrypted one has five.
• “Invalid base64url”: a character that does not belong, often a space, a quote, or a plus or slash from standard base64 instead of a hyphen or underscore.
• “Token expired” by a small margin: clock differences between the machines, solved by a leeway of a few minutes.
• “Invalid audience” or “invalid issuer”: the token was made for a different service or by a different tenant than the one validating it.
• “Invalid signature” for ES256 tokens: a signature produced in DER form instead of the format JWT requires, or the wrong curve.
• “Algorithm not allowed”: the service accepts only certain algorithms, and the token uses another.

Is it safe to paste a token here?

This page decodes your token in your browser, and the code behind it makes no network requests, so the token is not uploaded to us or anyone else. You can confirm that in the Network panel of your browser's developer tools. Nothing is saved, and the token is not placed in the address of the page.

Still, a live token works like a password until it expires. Prefer expired or test tokens when you can. Pasting a real token into any web page, including this one, leaves a copy in your clipboard history and possibly in your browser's form memory. If you pasted a token into a site you do not trust, treat it as exposed, sign out so the session ends, and rotate any long-lived credentials.

Limits and accuracy

• Decoding and the checks cannot prove that a token is genuine. Only the signature check with the right key can, and the service that accepts the token must do its own verification.
• The checks read only the token. They cannot know what your service expects for the issuer, audience, or lifetime, and some warnings, such as a long lifetime, are advice rather than rules.
• An encrypted token (JWE) can be read only as far as its header. The payload needs the recipient's private key, which this page does not accept.
• Verification supports HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, and EdDSA with Ed25519. Ed25519 depends on your browser supporting it, and Ed448 is not supported.
• A certificate is used only to get its public key. Its validity period, chain, and revocation are not checked.
• The provider and token-type labels are recognized from the issuer address and the claims, so they are good guesses and not facts.
• Dates are checked against this device's clock. If the clock is wrong, a valid token may look expired.

Frequently asked questions