JWT Decoder & Validator

Decode a JWT and read every claim, including the timestamps

Paste a JSON Web Token into the box above and it splits at the dots, base64url–decodes the first two segments, and prints the header and payload as formatted JSON. Decoding starts as soon as text lands in the field — there is no submit button. Every timestamp claim (exp, nbf, iat) is rendered twice: the raw integer as it appears in the token, and the same value converted to a readable local date and time, so you can answer “when did this expire” without opening a converter.

All of it runs in your browser. The token is never sent to a server, never logged, and never stored. The one exception you should know about: the decode tab mirrors the token into the address bar as ?token= so the “Copy shareable link” button can hand someone the same view. That link carries the token in it. Decoding is still local, but the link itself is the token — do not paste a production access token and then share the URL. The URL is written with history replacement rather than a push, so tokens do not pile up in browser back–history.

This tool decodes and inspects. It does not verify signatures on the decode side. That distinction is not a limitation to work around — it is the whole point of a decoder. A JWT payload is base64, not ciphertext, so anyone holding the token can read it whether the signature is good or forged. Reading claims and trusting claims are separate acts, and only your backend, holding the key, can do the second one.

The claim–by–claim reference

The seven registered claims from RFC 7519 are what the tool lists under “Standard Claims”. Everything else in the payload is shown separately as a custom claim. Here is what each one is actually for, and what breaks when it is wrong.

Header claims are a shorter list. alg names the signing algorithm, typ is conventionally JWT, and kid — the key ID — tells the verifier which key from a JWKS endpoint signed this token. When you are debugging a verification failure against a rotating key set, kid is the field to compare against the keys the verifier actually has.

How to read an expired token’s timestamps

Every NumericDate claim is seconds since 1970–01–01 UTC, not milliseconds. This is the single most common source of nonsense timestamps. If your decoded exp renders as a date tens of thousands of years in the future, the issuer emitted Date.now() from JavaScript without dividing by 1000. If it renders in early 1970, someone divided twice. Both are issuer bugs, not decoder bugs, and both are obvious the moment the integer is shown next to its human–readable form.

Once a token decodes, the tool computes a status panel from the payload’s time claims against your machine’s clock and shows one of four states:

• Valid — exp is in the future and nbf, if present, has passed. The panel also shows time remaining, and escalates its warning level as expiry approaches.
• Expired — exp is in the past. The panel says how long ago, in seconds, minutes, hours or days.
• Not yet valid — nbf is still in the future, so a correct verifier will refuse the token even though it has not expired. Almost always a clock–skew problem between issuer and consumer.
• No expiration — there is no exp claim at all. Flagged as a warning, because a bearer token with no expiry is valid until the signing key is rotated or the token is explicitly revoked.

Alongside the status you get the absolute expiry time, the issue time, the not–before time, and token age computed from iat. When a token works on one machine and fails on another, compare token age here against the clock on the failing host — a verifier with a clock a few minutes fast will reject freshly issued tokens as not–yet–valid, and one running slow will accept tokens past their expiry.

What “signature verification failed” actually means

A JWT signature covers exactly the first two segments joined by a dot: base64url(header) + "." + base64url(payload). The third segment is the signature over that byte string. Verification recomputes it and compares. So “signature verification failed” means one of a small number of concrete things, and the decoded header and payload above tell you which:

• Wrong key. With HS256 the verifier is using a different secret than the signer. With RS256 or ES256 it is using a public key that does not pair with the signing private key — usually a stale JWKS cache after a key rotation. Compare the header’s kid with the key IDs the verifier holds.
• Secret encoding mismatch. An HMAC secret is bytes. If the signer treated a base64 string as base64–decoded bytes and the verifier treated the same string as raw UTF–8, both sides “have the same secret” and the signature still fails. This is extremely common with secrets copied out of a config UI.
• Algorithm mismatch. The verifier is configured for one algorithm and the header declares another. Well–behaved libraries refuse rather than following the header — see the next section for why.
• The token was altered. Any edit to the header or payload, including re–serialising the JSON with different key order or whitespace, changes the signed bytes. You cannot decode a JWT, tweak a claim, re–encode it, and keep the signature.
• The token was mangled in transit. Truncation by a field length limit, a line break inserted by a copy–paste through a terminal or an email client, a stray space after Bearer, or URL–encoding applied to the token. If the tool above reports “Invalid JWT format. Expected 3 parts separated by dots.”, the token is damaged before verification is even reached.

Two errors get confused with signature failure and are not it. “Token expired” means the signature verified perfectly and then exp failed — a valid signature over a stale token. “Invalid audience” or “invalid issuer” likewise happen after a successful signature check. If your error message names a claim, the cryptography was fine and the policy check was not.

Algorithm confusion and alg: none

The header declares which algorithm signed the token. That is metadata written by whoever produced the token, which in an attack means it is written by the attacker. Two classic exploits follow directly from a verifier that trusts it.

alg: none. RFC 7519 defines an unsecured JWT: algorithm none, empty signature segment, so the token ends with a trailing dot and nothing after it. A verifier that reads alg from the header and dispatches on it can be handed {"alg":"none"} with any payload the attacker likes and will accept it, because “verifying” a none token is a no–op. The tool flags any decoded token whose alg is none as critical for exactly this reason. The builder tab can produce unsigned tokens too — useful for testing whether your own verifier rejects them, which is the only reason to generate one.

RS256 to HS256 confusion. An attacker takes a service that signs with RS256, rewrites the header to HS256, and signs the token using the service’s public key as the HMAC secret. A verifier that dispatches on the header algorithm will fetch the public key it was configured with, use it as an HMAC key because the header said HMAC, and the signature will check out. The public key is public, so the attacker forges arbitrary tokens.

The fix for both is the same one line of configuration: pin the accepted algorithms at the verifier and never let the token choose. Pass an explicit allowlist — algorithms: ["RS256"] or the equivalent in your library — and reject anything else before any key is loaded.

The tool grades the header algorithm whenever a token decodes: the RSA, ECDSA and RSA–PSS families are marked as sound choices, the HMAC family is flagged as symmetric — every party that can verify a token can also mint one — none is flagged as critical, and anything unrecognised is flagged for review.

base64url, not base64 — why segments will not decode elsewhere

JWT segments are base64url–encoded (RFC 4648 §5), not standard base64. Two differences matter in practice:

• Characters 62 and 63 are - and _ instead of + and /. A plain base64 decoder either errors or silently produces garbage when it meets them.
• Trailing = padding is stripped. Standard base64 decoders often demand a length that is a multiple of four.

To decode a segment by hand, translate - to + and _ to /, then append = until the length is a multiple of four. That is precisely what this tool does internally before decoding, which is why pasting a raw segment into a generic base64 decoder can fail on a token this page reads without complaint.

There is a second, subtler consequence: because + and / are absent, a JWT is safe in a URL query string and in a form field without further encoding. If you see %2B or %2F inside a token, something has base64–encoded a JWT a second time or URL–encoded standard base64 — either way the token you have is not the token that was issued.

Two conveniences beyond the spec. If the input is a single segment rather than three, it is decoded as plain base64 and pretty–printed when the result parses as JSON. And if a token arrives lowercased — by a logging pipeline, a case–insensitive database column, or a shell — the tool attempts case recovery, scoring candidate decodings chunk by chunk for text–likeness and reporting high, medium or low confidence along with the recovered base64. Base64 is case–sensitive, so this is reconstruction, not decoding: low confidence means go and get the original token.

Building and signing a token

The Build JWT tab creates and signs tokens in the browser using the jose library, loaded on demand only when you press generate. Nothing you type — secret, private key, or claims — leaves the page.

• Algorithm: HS256/384/512, RS256/384/512, ES256/384/512, PS256/384/512, or none for an unsigned token.
• Registered claims: fields for iss, sub, aud and jti. A comma in the audience field produces the array form of aud. A button fills jti with a random 16–byte hex value from the browser’s crypto source.
• Time claims: iat is set to now by default and can be switched off. exp takes a preset of one hour, one day, one week or thirty days, an explicit datetime, or none at all. nbf is off by default and takes a datetime.
• Custom claims: add any key with a declared type — string, number, boolean, JSON array or JSON object — and invalid JSON is reported before signing rather than silently coerced to a string.
• Custom header claims: add fields such as kid alongside the generated alg and typ.
• Keys: HMAC algorithms take a secret string, which is used as its raw UTF–8 bytes. Asymmetric algorithms take a PEM–encoded PKCS#8 private key, typed in or loaded from a file — the block beginning -----BEGIN PRIVATE KEY-----. A PKCS#1 key (BEGIN RSA PRIVATE KEY) is rejected; convert it to PKCS#8 first.

A live preview shows the header and payload JSON as you edit, so you can see the claim set before committing to it. After generating, the token appears with its three encoded parts listed separately and individually copyable, and one button loads it straight into the decode tab — the quickest way to confirm that a claim landed where you meant it to.

Common mistakes when reading a token

• Treating the payload as private. A signed JWT is signed, not encrypted. Anyone with the token reads every claim, exactly as this page does. Never put a password, an API key, a full national identifier or anything else confidential in a payload. If claims must be hidden, you need JWE, not JWS.
• Copying the whole header value. The Bearer prefix is part of the HTTP Authorization header, not part of the token. Paste only what follows the space.
• Trusting a decoded claim in application code. Decoding proves nothing. Any client–side check on a decoded claim is a display convenience; the authorisation decision belongs on the server, after verification.
• Assuming an expired token is the problem. Check the status panel before rebuilding your auth flow — the expiry might be fine and the failure might be aud, iss, or a rotated key.
• Confusing an ID token with an access token. In OpenID Connect, the ID token describes the user and is meant for the client; the access token is the credential for the API. Both decode identically here; the aud claim is what tells them apart.

When to use something else

Use a verifying library, not a decoder, whenever the answer affects an authorisation decision — that means your language’s JWT library with an explicit algorithm allowlist, the issuer’s JWKS endpoint, and expected iss and aud values. Use a JWE library if the claims themselves need confidentiality. If your string is not a JWT at all — no dots, or segments that will not decode to JSON — a general encoding tool such as the Base64 encoder and decoder is the better place to start, since it auto–detects hex, Base32, URL encoding and other formats that get mistaken for tokens.