| Claim | Value | Meaning |
|---|
Paste your JWT (in the header.payload.signature format) into the input box. The token is decoded instantly and entirely in your browser.
Read the pretty-printed header and payload JSON, the algorithm badge, and the expiry status (valid, expired, or not yet valid) computed from the exp and nbf claims.
Review the claims table, which explains each standard claim — iss, sub, aud, exp, iat, nbf, jti — in plain language with human-readable timestamps.
Optionally expand the verification panel and paste an HMAC secret or a PEM public key to verify the signature locally with the Web Crypto API. The key is never transmitted.
Paste a token and see its decoded header and payload as syntax-highlighted JSON immediately. No button to press and no round-trip to a server — decoding happens as you type.
Every claim is explained. Registered claims like exp, iat, and nbf are converted from Unix timestamps into readable dates, and custom claims are clearly labelled, so you understand exactly what the token asserts.
The tool compares the exp and nbf claims against the current time and shows a clear status badge — valid, expired, or not yet valid — so you can spot the most common authentication bug at a glance.
Verify HS256/384/512 with a shared secret, or RS and ES algorithms with a PEM public key, using the browser's built-in Web Crypto API. No external libraries and, critically, no transmission of your secret or key.
Tokens often contain personal data, session identifiers, or credentials. Everything here is processed in your browser — the token, the secret, and the key never leave your device, unlike popular tools that post the token to their server.
The best-known online JWT tool sends your token to its server to "verify" it. A JWT frequently carries user PII, scopes, or a live session credential, so transmitting it is a real security risk. This decoder runs entirely client-side — you can watch the network tab and see that nothing is sent. No account, no logging.
Beyond showing the JSON, it interprets every standard claim, converts timestamps to dates, and flags expiry and not-before problems — the exact issues that break logins. It turns an opaque string into an answer to "why is this token being rejected?"
Signature checking uses the Web Crypto API that ships in every modern browser, supporting HMAC, RSA, and ECDSA. You get genuine verification, not a decorative checkmark, while your secret or public key stays on your machine.
The tool is explicit that decoding is not verification, that a decoded payload is not trustworthy until the signature checks out, and that secrets are never persisted to the URL or local storage. It teaches the right mental model rather than hiding the details.
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It is most commonly used for authentication and authorization: after you log in, a server issues a signed token, and your client sends it back on each request to prove who you are. A JWT is not encrypted by default — it is signed. Anyone who holds the token can read its contents; the signature only guarantees that the contents have not been tampered with and that they were issued by someone holding the signing key.
That distinction is the single most important thing to understand about JWTs, and it is why a decoder like this can read any token without a secret, while verifying its authenticity requires the key.
A JWT is three base64url-encoded segments joined by dots: header.payload.signature.
alg, e.g. HS256 or RS256) and the type (typ, usually "JWT"). It may include a key id (kid) pointing to which key signed it.The JWT specification defines a set of registered claims with agreed meanings:
iss (issuer) — who created and signed the token.sub (subject) — the principal the token is about, often a user id.aud (audience) — the intended recipient; a token meant for one API should be rejected by another.exp (expiration) — a Unix timestamp after which the token must be rejected.nbf (not before) — a timestamp before which the token is not yet valid.iat (issued at) — when the token was created.jti (JWT id) — a unique identifier, useful for revocation lists.This tool converts the timestamp claims into human-readable dates and shows whether the token is currently within its valid window — the most frequent source of "it works on my machine but fails in staging" authentication bugs, which are often just clock or expiry issues.
The signature is computed over the string base64url(header) + "." + base64url(payload). With a symmetric algorithm like HS256, the same secret both signs and verifies, using an HMAC with SHA-256. With an asymmetric algorithm like RS256 or ES256, a private key signs and the corresponding public key verifies — which is why services can publish their public key (often via a JWKS endpoint) so anyone can validate tokens without being able to forge them. To verify in this tool, you provide the HMAC secret or the PEM public key, and the browser's Web Crypto API recomputes and compares the signature locally.
exp, or a server that does not check it, is a long-lived credential waiting to be stolen.In most real systems you will encounter two kinds of token. The access token is a short-lived JWT presented on each API call; it is designed to expire quickly so that a stolen one is useful only briefly. The refresh token is a longer-lived credential held more carefully and exchanged at the auth server for a fresh access token when the old one expires. Confusing the two leads to insecure designs — for example, giving an access token a multi-day lifetime to avoid frequent logins. The correct pattern is a short access-token expiry combined with a refresh token, so this decoder showing an exp only minutes away is usually a sign the system is configured correctly, not a bug. Reading the expiry here helps you confirm that your token lifetimes match your intended security posture.
It bears repeating in its own section, because it is the single most common misunderstanding about JWTs: everything this page shows you about a token's header and payload comes from decoding, not from verifying. Decoding is just reversing base64url encoding to reveal JSON — anyone can do it to any token, with no key at all, which is exactly how this tool can display a token's contents the instant you paste it in. That readability is not an endorsement of the token's authenticity. Trusting a claim like sub or role without checking the signature against a key you control is how forged tokens slip through — the payload of an unverified token is, from a security standpoint, no more trustworthy than a claim typed into a text file. Our companion article on why decoding a JWT does not verify it walks through concrete examples of what can go wrong when an application skips this step.
| Claim | Full Name | What It Means |
|---|---|---|
| iss | Issuer | Identifies who created and signed the token, so a verifier can check it came from an expected authority. |
| sub | Subject | The principal the token is about — typically a user ID or service account identifier. |
| aud | Audience | The intended recipient of the token; a service should reject a token whose audience names a different API. |
| exp | Expiration Time | A Unix timestamp after which the token must be rejected outright, no matter how valid the signature is. |
| nbf | Not Before | A Unix timestamp before which the token must not yet be accepted, useful for pre-issued tokens. |
| iat | Issued At | When the token was created, useful for auditing and for computing token age. |
| jti | JWT ID | A unique identifier for the token, useful for tracking or revoking one specific token. |
All seven are defined in the JWT specification, RFC 7519; none of them are required, but a well-designed authentication system typically sets at least iss, sub, exp, and iat.
A common support ticket reads: "I'm getting a 401 Unauthorized and I don't know why — the token looks fine." Here is how this decoder answers that in seconds using the built-in HS256 example. Paste the example token in and the header shows algorithm HS256 with type JWT, nothing unusual. The payload shows sub: "user_42", a name, a role of "admin", an iat of a Unix timestamp corresponding to a specific moment, and an exp exactly one hour later. The status badge reads "Expired," and the human-readable timestamps make the reason obvious at a glance: this token was only ever valid for a single hour after it was issued, and that hour is now long in the past. That is the entire 401: the server's middleware checked exp against the current time, found it in the past, and correctly rejected the request before ever looking at the signature. The fix is not a code change on the client — it is requesting a fresh token (or using the refresh token, if the application has one) instead of continuing to send an access token whose lifetime has already elapsed.
No. The entire process — decoding the header and payload, interpreting claims, checking expiry, and verifying the signature — happens in your browser. Your token, any secret, and any key never leave your device. You can confirm this by watching your browser's network tab while you use the tool; no request is made.
Yes. A JWT is signed, not encrypted, so the header and payload are readable by anyone who holds the token. The decoder shows them immediately without any key. You only need a secret or public key for the optional step of verifying that the signature is authentic.
The tool reads the exp (expiration) and nbf (not before) claims and compares them to the current time. 'Valid' means the token is within its allowed window, 'Expired' means the current time is past exp, and 'Not yet valid' means nbf is in the future. Tokens without an exp claim show 'No expiry claim'.
Signature verification supports HMAC (HS256, HS384, HS512) with a shared secret, RSA (RS256, RS384, RS512) with a PEM public key, and ECDSA (ES256, ES384, ES512) with a PEM public key. Verification uses the browser's built-in Web Crypto API, so no external library is loaded.
Decoding simply base64url-decodes the segments to reveal the JSON; it tells you what the token claims but not whether those claims are trustworthy. Verifying recomputes the cryptographic signature with a key you supply and confirms the token was issued by the holder of that key and not altered. Always verify before trusting a token.
Because everything is client-side and nothing is transmitted, pasting a token here does not expose it over the network. As good practice, avoid pasting live production credentials into any web page, and prefer short-lived test tokens. This tool is designed precisely so you do not have to send tokens to a remote server to inspect them.
No. The secret or key you enter for verification is used only in memory for the verification call and is never written to the URL, local storage, or anywhere else. Reloading the page clears it entirely.
Yes, completely free with no registration, no limits, and no ads injected into results. Decoding, claim interpretation, expiry checking, and local signature verification are all available at no cost, with every operation running privately in your browser.
No. Displaying the claims only proves you can read what the token asserts, not that those assertions are genuine. A token can be decoded by anyone with no key at all. Only verifying the signature against a key you trust tells you the token was actually issued by its claimed issuer and has not been tampered with.
Most production systems set at least iss (who issued it), sub (who it is about), exp (when it expires), and iat (when it was created), often alongside aud to scope the token to one API. A token missing exp entirely is worth investigating, since it behaves like a long-lived, hard-to-revoke credential.
Standard Base64 uses +, / and = that break URLs, JWTs and filenames. Learn the url safe base64 vs standard base64 difference and how to fix decode errors.
Read more →
Fix JWT token expired errors caused by the exp claim — clock skew, timezone bugs, refresh failures, and leeway — with a fast browser-based decoder workflow.
Read more →
Decoding a JWT only reads its claims; verifying checks the signature. Learn the difference, why it causes auth bugs, and how to test both safely.
Read more →
Understand JSON Web Tokens: structure, claims, signing vs encryption, expiry, and signature verification — plus the security mistakes that cause auth bugs.
Read more →