Decode and inspect JWT tokens in your browser. See the header, payload, claims, and expiry, and verify signatures locally. Your token is never uploaded.
| 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.
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.