JWT Validator
Check a JWT's structure and time claims - signature is never verified, so the verdict is about usability, not authenticity.
Before a token is usable it has to be well-formed, and before it is trusted it has to be verified. This validator handles the first part: it checks that a JWT has the correct three-segment structure, that the header and payload are valid Base64URL-encoded JSON, that the algorithm field is a recognized one, and that the time claims - exp, nbf and iat - line up with the current clock.
Paste a token and press Validate. The result lists everything checked: segment count, header and payload validity, the algorithm, and each time claim with the date it refers to. An expired token is flagged with the exact expiry time, so you can see at a glance why a request was rejected.
It is important to be precise about what this tool does not do: it does not verify the signature. Checking structure and expiry requires no secret key and proves nothing about who issued the token. A token that passes every check here could still have been fabricated by anyone - genuine verification needs the issuer's key and a signature check.
Features
- Check segment structure, header and payload JSON, and the alg field in one pass.
- Interpret time claims: exp, nbf and iat are converted to readable dates with expiry flagged explicitly.
- Report every issue found, in order, instead of a single yes-or-no verdict.
- Flag unrecognized algorithms and clearly state the check never verifies the signature.
- Runs entirely in your browser - the token never leaves your device.
How to Use
- 1
Paste the token
Copy the full three-segment JWT into the input box. Trimming whitespace is handled automatically.
- 2
Press Validate
Hit Validate (or Ctrl+Enter). The report lists the structural checks and every time claim with its interpreted date.
- 3
Read the issues
If the token has problems, each one is listed with the reason - wrong segment count, invalid JSON, unrecognized algorithm, expired, or not yet valid.
- 4
Understand the scope
Treat a clean report as "this token is well-formed and within its time window". It is not a statement that the token is authentic. Signature verification is a separate step performed by the issuing service.
Example
Well-formed token with a future exp
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMzQiLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6MTc1MDAwMDAwMH0.SflKxwRJ↓
✓ Token looks well-formed and usable.
Structure: 3 segments ✓
Header: valid JSON (alg: HS256) ✓
Payload: valid JSON
exp: 2025-06-15 ...
Issues: (none blocking)Common Problems
Reading a validation result as proof of authenticity
This check has no key and makes no claim about who signed the token. A well-formed, unexpired token can still be fabricated. Verification - confirming the signature against the issuer's key - is a separate, server-side responsibility.
Treating an expired token as acceptable
exp is the issuer's contract for how long the token is valid. Serving an expired token is a security failure; the correct response is to re-authenticate and obtain a fresh one.
Mistaking nbf for exp
nbf (not before) sets the earliest moment a token is valid; exp sets the latest. A token can fail either bound. This validator reports both separately so the two are not confused.
Ignoring the alg value
alg names the intended signing algorithm. A token with an unrecognized or downgraded algorithm (for example "none") should be rejected before it is ever used, regardless of how its payload reads.
Validating tokens from multiple issuers with one rule set
Different services issue tokens with different algorithms, expiry windows and claim shapes. A single blanket policy can flag valid tokens or accept invalid ones. Know which issuer a token claims (the iss claim) and apply that issuer's expectations to it.
Technical Details
The validator splits the token on dots and requires exactly three segments. It then Base64URL-decodes the header and payload and parses each as JSON, checking that both are objects.
The alg field is matched against the standard JWA algorithm names (HS256/384/512, RS256/384/512, ES256/384/512, PS256/384/512). An unrecognized value is flagged rather than silently accepted.
Time claims are compared against the current time in seconds since the epoch. exp is required to be in the future, nbf in the past, and iat within a small tolerance of the present.
This tool performs no cryptographic verification. It has no key and makes no attempt to check the signature, which is why a clean result never implies authenticity.
Everything runs client-side. The token is parsed in memory and nothing is transmitted.
The time comparison uses the browser's current clock. If your clock drifts, expiry verdicts shift with it - for strict checks, servers typically allow a small clock-skew tolerance in both directions.
Frequently Asked Questions
Does this validator verify the JWT signature?
No. Signature verification requires the issuer's secret or public key and a cryptographic check. This tool checks only structure, JSON validity and time claims. A token that passes here may still be a forgery - treat validation as a prerequisite, not a proof of authenticity.
Why does it flag my token as expired?
The token's exp claim names a moment in the past relative to your current clock. Some services issue short-lived tokens precisely to reduce risk, so an expired token is usually expected to be replaced by re-authenticating, not to be accepted.
What makes a token invalid besides expiry?
A wrong segment count, a header or payload that is not valid JSON, a non-object payload, a missing or unrecognized alg, an nbf that has not arrived yet, or an iat in the future. The validator lists every problem it finds so you can fix them in one pass.
Is my token uploaded when I validate it?
No. Validation runs entirely in your browser. The token is parsed in memory and never transmitted, stored or logged.
What is the difference between this and JWT Decoder?
The decoder reads and displays the header, payload and claims. The validator evaluates whether the token is well-formed and within its time window. Both avoid signature verification - decoding shows what a token says, validation checks that it is structurally usable.
How should I store a token after validating it?
Validation here only tells you the token is structurally sound. After a genuine server-side verification, store the token where its risk profile fits - short-lived tokens in memory, and never in plaintext in logs. The claims it carries are sensitive by themselves, even when the token is not.
Data & Privacy
Your data stays in your browser. Nothing is uploaded.
- Processing
- Local
- Upload
- None
- Server Storage
- None
- Account
- Not required
Related Tools
JWT Decoder
Inspect the header, payload and claims of a JSON Web Token - decoded locally, never uploaded.
Security & Tokens
Hash Generator
Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests of any text, in your browser.
Security & Tokens
Random String Generator
Generate secure random strings and passwords with control over length and character set.
Security & Tokens
HMAC Generator
Sign a message with a secret key using HMAC-SHA256 or HMAC-SHA512, right in your browser.
Security & Tokens
UUID Generator
Generate random UUID v4 identifiers in bulk, with or without dashes, in your browser.
Security & Tokens
JSON Formatter
Format, validate and beautify JSON directly in your browser.
JSON & Data
Related Guides
What Is a JWT? How JSON Web Tokens Work
A JSON Web Token (JWT) is a compact, signed token of three base64url parts: header, payload and signature. Learn why it is not encryption.
How to Decode a JWT: Read the Header and Payload Without a Secret
Decode any JWT by splitting on the dots and base64url-decoding the header and payload. No secret is needed, because decoding is not signature verification.
JWT Header Explained: alg, typ and kid
The JWT header is the first base64url segment and declares the signing algorithm. Learn what alg, typ and kid mean and why alg=none is a known attack vector.
JWT Payload Explained: Claims Like sub, iss, aud and exp
The JWT payload holds the claims: sub, iss, aud, exp, nbf, iat and jti. Learn what each registered claim means and why the payload is readable by anyone.
JWT Expiration Explained: exp, iat, nbf and Refresh Tokens
The exp claim sets when a JWT stops being valid. Learn how exp, iat and nbf work, how servers enforce expiry and how refresh tokens extend a session.