Home›Validators›Security›JWT Validator

JWT Validator

Security

Validate and decode JSON Web Tokens (JWT) instantly. Checks structure, decodes header and payload claims, and flags expired tokens — client-side only.

Headerjson
{
"alg": "HS256",
"typ": "JWT"
}
Payloadjson
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

What is a JWT?

The JWT Validator decodes and checks the structural validity of a JSON Web Token (JWT) — the compact authentication token format used in virtually every modern REST API, OAuth 2.0 implementation, and OpenID Connect identity flow.

A JWT consists of three Base64URL-encoded sections joined by dots: header.payload.signature. The header is a JSON object containing the signing algorithm (alg) and token type (typ). The payload is a JSON object containing the claims — who the token is about, when it expires, who issued it, and any application-specific data. The signature cryptographically binds the header and payload to a secret key, preventing tampering.

This validator:

  • Confirms the token has the correct three-part structure
  • Base64URL-decodes the header and payload and parses them as JSON
  • Displays all decoded claims with Unix timestamps converted to human-readable ISO 8601 dates
  • Checks the exp (expiry) claim against the current time and reports whether the token is live or expired
  • Reports the signing algorithm (alg) from the header — alerting you if dangerous values like none are present

What it does not do: Cryptographic signature verification requires the signing secret (HS256/384/512) or public key (RS256, ES256). Without the key, it is not possible to confirm that the token was signed by the claimed issuer — only that the signature field is structurally present. For production signature verification, use a JWT library with the correct key in your server code.

All decoding runs client-side in your browser. Tokens are never transmitted or stored — critical for tokens containing sensitive claims like user IDs or roles.

Use the Password Strength Validator for evaluating password security, or the JSON Validator if you need to validate a raw JSON payload outside of a JWT context.

How to use this JWT calculator

  1. Find your JWT — copy it from an Authorization header (Bearer eyJ...), browser localStorage/sessionStorage, a Postman response, a debug log, or a curl output. Remove the Bearer prefix if present — paste only the token itself.
  2. Paste the token into the "JWT Token" textarea.
  3. Check the Valid/Invalid badge — green means the structure is correct and all three sections decode to valid JSON; red means a structural problem was found.
  4. Read the details panel — header claims first (algorithm, type), then payload claims (all key-value pairs with timestamps in ISO format), then expiry status, then signature note.
  5. Check the expiry line — if the token has expired, the details show exactly when and how long ago, which immediately identifies whether a token refresh is needed.
  6. Note the algorithm from the header — confirm it is the expected algorithm for your system; flag alg: none immediately as a security concern.
  7. Compare claims to expectations — confirm iss, aud, sub, and any custom claims match what your server expects before concluding the auth issue lies elsewhere.

Formula & Methodology

JWT structure:

<Base64URL(header)>.<Base64URL(payload)>.<Base64URL(signature)>

Base64URL encoding differs from standard Base64 in two character substitutions: + → - and / → _, and trailing = padding is omitted. Decoding reverses these substitutions and re-adds padding before standard Base64 decoding.

Decoding algorithm:
1. Split the token on . — expect exactly 3 parts.
2. For each of header and payload: replace - with +, _ with /, pad to a multiple of 4 characters with =, then apply atob() to decode Base64 to a UTF-8 string, then parse as JSON.
3. Check that the resulting objects are valid JSON — malformed JSON in either section indicates a corrupted or truncated token.
4. Read header.alg for the algorithm, read payload.exp for the expiry Unix timestamp.

Expiry check: expired = payload.exp < Math.floor(Date.now() / 1000)

Valid and invalid examples:

| Token | Valid? | Note |
|---|---|---|
| eyJ...Z.eyJ...Z.sig (3 parts, valid JSON) | ✓ | Structurally valid |
| eyJ...Z.eyJ...Z (2 parts) | ✗ | Missing signature section |
| notbase64.notbase64.notbase64 | ✗ | Header/payload fail JSON parse |
| Valid structure, exp in past | ✓ structural / ⚠ expired | Token is well-formed but expired |
| eyJ..alg:none..Z.eyJ...Z. | ✓ structural / ⚠ insecure | Structurally valid but alg:none is a security risk |

Use the JSON Validator to validate the raw decoded payload JSON, or the Password Strength Validator for evaluating secrets used in HMAC-signed JWTs.

Frequently Asked Questions

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. It is a Base64URL-encoded string consisting of three dot-separated sections: a header (containing the algorithm), a payload (containing the claims), and a signature. JWTs are defined by RFC 7519 and are the most widely used format for stateless authentication tokens in REST APIs and single-page applications.
The validator checks that the token has exactly three dot-separated Base64URL-encoded sections, that the header decodes to valid JSON containing at minimum an alg field, and that the payload decodes to valid JSON. It then displays all decoded header and payload claims. It also checks the exp (expiry) claim against the current time if present, flagging whether the token has expired. Signature verification is structural only — confirming the signature segment exists — not cryptographic, because verifying the signature requires the signing secret or public key.
No — cryptographic signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256 and ES256). This tool performs structural validation and claim decoding only. To verify a signature in production, use the official JWT library for your language (jsonwebtoken for Node.js, python-jose for Python, jjwt for Java) with the correct signing key.
JWT claims are the key-value pairs encoded in the payload section of the token. Registered claims are defined by the RFC and have standard meanings: iss (issuer), sub (subject/user ID), aud (audience), exp (expiry Unix timestamp), nbf (not-before timestamp), iat (issued-at Unix timestamp), and jti (JWT ID). Public and private claims are application-specific and not standardised. The validator displays all claims, converting Unix timestamps to ISO 8601 date strings for readability.
The alg: none header indicates that no signature algorithm is applied — the token has no cryptographic signature. This is a known security vulnerability: an attacker can forge a JWT with alg: none and modify the payload without detection if the server accepts it. All production JWT validation libraries should reject alg: none tokens by default. The validator will flag the algorithm shown in the header so you can immediately identify alg: none tokens.
HS256 (HMAC-SHA256) is the most common algorithm for APIs where the same server signs and verifies the token. RS256 (RSA with SHA-256) and ES256 (ECDSA with P-256 and SHA-256) are asymmetric algorithms used in OAuth 2.0 and OpenID Connect flows where a third party (identity provider) signs tokens that a resource server verifies using a public key. HS384, HS512, RS384, RS512, ES384, and ES512 are higher-security variants of the same families.
No — all decoding and validation happens entirely in your browser using client-side JavaScript. Your token is never transmitted to any server, stored, or logged. The page validates completely offline once loaded. This is especially important for production tokens — even if the validator cannot verify your signature, you should avoid pasting live production JWTs containing sensitive claims into any web tool you do not fully control.
If the validator flags an expired token (exp claim in the past), the token must be re-issued — you cannot extend an expired JWT without generating a new one. In most authentication flows, your client application should automatically request a new access token using a refresh token when the access token expires. If you do not have a refresh token or it too has expired, the user must log in again. The iat claim shows when the original token was issued.
Paste your JWT into the 'JWT Token' textarea — the full token string (three dot-separated sections). The Valid/Invalid badge updates instantly. If valid, the details panel shows all header claims (algorithm, type), all payload claims with timestamps converted to ISO dates, an expiry status line, and a note about the signature. If invalid, the error message identifies which section failed and why.
A session token is a random opaque string that the server maps to session state stored in its own database — the server must query the database on every request to look up the session. A JWT is self-contained: all claims are encoded in the token itself, so the server can verify and read the payload without a database lookup, by checking the signature against a known key. JWTs are stateless and work across distributed services; session tokens require shared session storage but are immediately invalidable by deleting the server-side record.
JWT timestamps use Unix time — the number of seconds elapsed since 1 January 1970 00:00:00 UTC. This is a 10-digit integer for current dates, e.g. 1716239022 for 20 May 2024. The validator automatically converts all iat, exp, and nbf values to ISO 8601 format (e.g. 2024-05-20T10:23:42Z) for readability. This conversion is display-only — the raw numeric value in the token is unmodified.
Yes — paste the token your application receives and the validator immediately shows the decoded claims: user ID (sub), issuer (iss), audience (aud), issued time (iat), and expiry (exp). This lets you quickly confirm whether the token carries the expected claims, was issued by the expected issuer, and has not expired — the three most common sources of JWT-related authentication failures in development. Use the [JSON Validator](/json-validator/) if you need to validate the raw payload JSON directly.
Also known as
decode JWTJSON web token validatorJWT decodercheck JWT tokeninspect JWT claims