JWT Decoder & Inspector
Decode a JSON Web Token to inspect its header, claims, expiry times, issuer and signature — with a built-in security check.
Paste any JWT — an access token from an API, an OAuth/OIDC token from your browser's dev tools, a token your backend rejected — and it is split into its three header.payload.signature parts, base64url-decoded, and laid out for inspection: the full header and payload as formatted JSON, a plain-English table of every registered claim (issuer, subject, audience, expiry, not-before, issued-at, jti and more) with each timestamp shown in your local time and UTC, a security findings panel that flags unsigned tokens, weak or unusual algorithms, missing or long-lived expiry, and signature-size mismatches, and the raw signature as a hex dump.
Token (paste the full token, including all three dot-separated parts)
waiting for a tokenToken anatomy
A JWT is three segments joined by dots. Header and payload are base64url-encoded JSON; the signature covers the first two segments.
Header (metadata)
Payload (claims)
Claim inspector
Registered (standard) claims are explained in plain English; custom claims are listed separately with their JSON type. Timestamps are shown in your local time and UTC.
| Claim | Value | Meaning |
|---|
Custom claims
| Claim | Value | Type |
|---|
Security findings
Static checks against the header and claims — a fast triage of what looks suspicious, not a substitute for real signature verification.
Signature
The signature is shown as raw bytes only. Verifying it requires the issuer's cryptographic key, which this tool never asks for and never has.
How a JWT is built
A JSON Web Token (RFC 7519) is a compact, dot-separated string of three parts:
- Header — JSON declaring the signing algorithm (
alg) and token type (typ, normally"JWT"). It may also carry akid(key ID) telling the verifier which key to use. - Payload — JSON of claims: statements about the token. The registered claims are
iss(issuer),sub(subject),aud(audience),exp(expiry),nbf(not before),iat(issued at) andjti(unique ID). OIDC adds userinfo claims likeemailandname. - Signature — a cryptographic signature over
base64url(header) + "." + base64url(payload), computed with the issuer's key.
Both JSON parts are encoded with base64url — the URL-safe variant of base64
(uses - and _ instead of + and /, and
drops padding). Because base64url is a plain encoding, decoding it reveals the JSON
instantly to anyone. That is by design: JWTs carry information, not secrecy.
Decoding is not verification — why that matters
This tool (and every "JWT decoder" you'll find) only reverses the base64url encoding. It does not verify the signature: it cannot tell you whether the token was really issued by the claimed issuer, whether the claims were modified after signing, or whether the signature was produced with the legitimate key.
Verification is the relying party's job: it fetches the issuer's public keys (for
asymmetric algorithms, usually from a jwks_uri endpoint), picks the key named
by kid, recomputes the signature over the first two segments, and compares it
with the third. Only then does it check the claims — that exp is in the
future, nbf in the past, and that aud includes itself.
The classic failure this matters for: a server that "decodes and reads the claims" without verifying the signature will happily accept a token an attacker crafted by hand. If you're debugging a token your backend rejected, decode it here to see why (wrong audience? expired? missing claim?) — but trust the claims only after the signature checks out.
Common pitfalls this inspector flags
alg: none— an unsigned token. If your service ever accepted one, that's a critical vulnerability: any client can mint tokens freely.- Algorithm confusion &mdash> if a server expects RS256 but accepts HS256, an attacker can sign a token with the public key (used as the HMAC secret), because the public key is public. Strictly pin the expected algorithm.
- Missing
exp— a token that never expires can't be revoked by time; keep lifetimes short. - Long-lived tokens &mdash> access tokens should be short (minutes); if
exp − iatis hours or days, that's a refresh token wearing an access token's clothes. - Signature size mismatch &mdash> RS256 signatures are 256 bytes, ES256 is 64, HS256 is 32. A mismatch means the signature wasn't produced by the claimed algorithm.
- Pasting tokens into public tools &mdash> a JWT is a live credential. This page decodes locally in your browser; anything you paste elsewhere may be logged by that site.
Suggested
