What the JWT Validator Does
The JWT Validator checks a token's shape and temporal health and prints a bullet list of everything wrong with it — or a single confirmation line when nothing is. Paste the token, run the transform, and the output is a plain-text report: structure problems, parse failures, expired or not-yet-valid claims, and missing recommended claims, each as one actionable bullet. There are no options and no keys involved; the tool judges what a token declares about itself, not whether its signature is genuine.
Exactly five checks run, in order. The token must have three dot-separated segments. The header segment must Base64Url-decode to parseable JSON. The payload must also decode to parseable JSON, and within it the tool compares exp (expiry) and nbf (not-before) against the current clock. Finally it checks the presence of iss and sub, the two claims that identify who issued the token and who it is for. A token that passes all five reports ✓ Structure valid, no temporal issues.
Validator and verifier answer different questions, and keeping them separate is the point. The validator tells you a token is
well-formed and within its lifetime; it cannot tell you whether anyone trustworthy signed it. Signature tampering, algorithm confusion, and forged claims all pass a structural validation untouched — for those you need the
JWT HS256 Verifier with the secret, or your server's public-key verification path.
How the JWT Validator Works
The validation pipeline mirrors how JWT libraries fail in practice, cheapest checks first. Splitting on . and counting segments takes microseconds and catches the most common paste error — a truncated token or a JWE's five-segment form. Decoding the header next is the second-cheapest failure detector: Base64Url damage or non-JSON content surfaces immediately. Only then does the payload decode, because everything downstream of it — temporal checks, claim presence — depends on those parsed claims.
The temporal checks compare claim values against Math.floor(Date.now() / 1000) — current time as epoch seconds, the same units the standard mandates. If the payload defines exp and it is already in the past, the validator reports Expired (exp=...) with the raw value for reference. If nbf is defined and lies in the future, it reports Not yet valid (nbf=...). Both claims are optional in the standard; the validator only complains about them when they are present and violated.
The iss and sub presence checks are the opinionated part. The JWT standard marks both as optional — but a token without an issuer cannot be traced to a trust source, and a token without a subject usually cannot be matched to an identity at all. The validator treats their absence as a finding worth reporting, which matches how production auth logs treat them. A first-party test fixture without these claims will show bullets; that is informative, not an error you must fix.
Conspicuously absent: any signature handling. The validator never decodes the third segment, never imports a key, and never runs a comparison over it. Two tokens with identical structure and claims but different signatures validate identically — structural validity is orthogonal to authenticity. The tool's output even reports an expired token's expiry rather than failing, because "expired" and "invalid" are different diagnoses needing different fixes.
Using the JWT Validator
- Step 1 — Paste the token. The complete three-segment string, exactly as received. Whitespace around it is tolerated; a missing segment is reported, not repaired.
- Step 2 — Run the transform. No options exist — the tool has one job. Empty input produces empty output rather than a spurious failure report.
- Step 3 — Read the bullets. Each line is one independent finding: structure, header parse, payload parse, expiry, not-before, missing
iss, missing sub. A token can accumulate several at once — a truncated token with a broken payload reports both. - Step 4 — Triangulate with the decoder. When a bullet needs context — which claim is missing, what the expiry value actually is — paste the same token into the JWT Decoder, which shows the full parsed payload the validator's findings refer to.
- Step 5 — Close the loop with verification. A clean validation report is necessary but not sufficient. Take the token to the HS256 or RS256 verifier with the appropriate key before treating its claims as trustworthy.
Common Use Cases
First-line triage for auth failures. A rejected token usually fails for boring reasons: it expired while sitting in a queue, it was truncated by a log viewer, it never had the claims your middleware requires. The validator answers those in one run, before you start suspecting clock skew or key rotation.
Checking fixtures before wiring tests. Hand-crafted test tokens often carry a typo in a claim name or an expiry that silently expired last month. Running each fixture through the validator keeps a test suite's tokens structurally honest before failures start pointing at the wrong layer.
Debugging clock-skew symptoms. If nbf is a few seconds in the future relative to your browser but your server disagrees, the validator's timestamped findings give you the raw values to compare against the server's clock — the first concrete evidence in a skew investigation.
Teaching the failure modes. Each check reports independently, which makes the tool a compact demonstration of JWT's layered assumptions — structure before claims, claims before trust.
Worked Example
This token has an expired exp (epoch 1700000000 — November 2023) and no iss or sub claims:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEwNDIiLCJleHAiOjE3MDAwMDAwMDB9.8m0EOlpNl0c8bwxnDm0v3YzLkXoPZbGRGsQMq1Jl7Xs
Wait — that payload does contain sub. A cleaner demonstration of the report shape: a token whose payload is only {"role":"admin"} produces three bullets:
• Expired (exp=1700000000) ← only if an exp is present
• Missing iss claim
• Missing sub claim
and a structurally broken paste — two segments instead of three — reports • Token must have 3 dot-separated parts plus • Invalid header and • Invalid payload, since neither truncated segment parses. The stack of independent findings is the tool's real output: each line is separately actionable, and a clean token gets the single ✓ line instead.
The example above also shows what the validator cannot see: that token's signature was computed over a different payload than it carries, and no structural check notices. Validation said nothing about it — verification is a different tool.
Tips and Common Mistakes
- A clean report is not a trust statement. The five checks are shape and time only. Signature, issuer allow-listing, and audience checks are all out of scope — the receiving service must still verify what it cares about.
- Expired does not mean malformed. The tool reports expiry as a finding, not a parse failure. An expired token with perfect structure gets exactly one bullet; that distinction tells you whether to re-authenticate (expiry) or re-mint the token (structure).
- Missing
iss/sub may be intentional. Test fixtures and some machine-to-machine tokens legitimately omit them. The findings are a reminder to confirm the omission is deliberate, not a syntax error to chase. - The clock is your browser's. Temporal findings are computed against the machine running the page. If that clock is wrong, so are the expiry verdicts — worth remembering when a token looks expired hours early.
- Five-segment tokens are not JWTs to validate. A JWE (encrypted JWT) fails the three-segment check by design. That is correct behaviour — its payload is ciphertext, and structure validation of the decrypted form happens after decryption.
- Do not paste signed production tokens casually. The tool is local-only, but the habit matters: validate with fixtures where possible, and prefer expired tokens when you must paste something real.
Frequently Asked Questions
Does the validator check the signature?
No — it never touches the third segment. Signature verification requires the signing secret (HS256) or the issuer's public key (RS256), which is a different tool's job with different inputs. Structural validity and authenticity are independent properties: a token can pass validation with a forged signature, and a correctly signed token can fail validation for a missing claim.Why does it complain about missing iss and sub?
Both are optional in RFC 7519, but they carry the two facts almost every consumer needs — who issued this token, and who is it for. Their absence is a policy finding, not a syntax error: the tool flags them so you can confirm the omission is deliberate. A fixture without them that fails your service's claim checks is usually failing exactly here.What does the exp value in the finding mean?
It is the raw epoch-seconds value from the payload, reported for reference so you can convert it yourself — paste it into the
JWT Expiry Checker or any epoch converter to see the exact date. The validator compares it against current time and reports the violation; it does not attempt to guess your intended timezone or units.
Can this tool tell me why my server rejected a token?
Often, partially. Server rejections that stem from expired or not-yet-valid tokens, missing claims, or malformed structure show up here. Rejections from signature mismatch, audience mismatch, or issuer allow-listing do not — those need verification tooling. The pattern worth learning: validate first for cheap diagnoses, then verify for the expensive ones.Does it check algorithm strength, like alg:none or HS256 with weak secrets?
No. The header's
alg value is not examined — an
alg:none token with valid structure and current timestamps passes validation cleanly. Algorithm-level policy belongs to your verification layer, which should reject unsigned tokens outright and enforce minimum key strengths. The
JWT Decoder shows you the header when you need to see what algorithm a token claims.
Related Tools