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.

Reviewed by the thecalcu.com team · Last updated July 13, 2026

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.

Why Use a JWT Validator?

JWT debugging is one of the most common friction points in API integration and authentication work. The token is opaque at a glance, three blocks of seemingly random characters, and errors manifest as cryptic 401/403 responses that give no indication of whether the problem is an expired token, a wrong issuer, a missing claim, or a signature mismatch.

Development debugging: An Indian fintech startup's mobile app receives 401 errors from their Go backend intermittently. Pasting the token from the app into the validator immediately shows exp: 1716000000 (2024-05-18T08:00:00Z, 32 minutes ago). The access token lifetime is set too short and the refresh logic is broken, cause identified in seconds.

Integration debugging: A developer integrating with Google OAuth 2.0 receives an ID token and needs to confirm the aud claim matches their registered client ID and the iss claim is accounts.google.com. Pasting the token shows both claims and their exact values, no base64url decode library or manual JWT inspection needed.

Who Should Use This Validator?

Backend developers building authentication and authorisation systems who need to quickly inspect a token's claims during development. Paste the token from a debug log, a Postman response, or a browser storage inspector and immediately see every field.

Front-end engineers debugging auth flows in single-page applications. When the React or Vue app is sending a stored JWT but the API returns 401, confirming that the token has expired or has the wrong audience resolves the issue before writing a single line of debug code.

Security engineers auditing JWT implementations. Check algorithm choice (reject alg: none; prefer RS256/ES256 over HS256 for distributed systems), confirm exp is set, verify audience (aud) restriction is present, and inspect any custom claims for sensitive data that should not be in a client-readable token.

QA engineers and tech leads reviewing auth behaviour in staging environments. Pair with the URL Validator when debugging redirect URIs in OAuth flows.

Indian SaaS developers integrating with international identity providers (Auth0, Cognito, Firebase, Azure AD) who need to inspect ID tokens and access tokens to understand claim structures before implementing server-side validation logic.

What Insights Does the JWT Validator Give You?

The details panel shows a structured breakdown of every decoded field in the token:

Header section:

  • alg, the signing algorithm. HS256 means a shared secret; RS256 means RSA asymmetric key; none is a critical security red flag.
  • typ, almost always JWT; sometimes at+JWT for OAuth 2.0 access tokens.
  • kid, key ID, present in multi-key setups (e.g. Google's rotating JWKs).

Payload section:

  • All standard claims displayed with Unix timestamps converted to ISO 8601 dates
  • exp additionally shows live/expired status with time remaining or time since expiry
  • Custom claims (user roles, permissions, tenant IDs) are shown exactly as encoded

Signature section:

  • Confirms the signature field is present and structurally non-empty
  • Notes that verification requires the signing key, prevents false confidence from structural validity

Scope boundary: A "Valid" result means the token is structurally well-formed and its claims are readable. It does not mean the token was issued by a legitimate authority, that the signature is authentic, or that the token grants any specific access rights in any particular system.

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.
Show formula & methodology ↓Show less ↑

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

What is a JSON Web Token (JWT)?
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.
What does the JWT Validator check?
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.
Can this tool verify the JWT signature?
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.
What are JWT claims?
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.
What does 'alg: none' mean and is it safe?
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.
What are the most common JWT algorithms?
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.
Is my JWT token stored or sent anywhere when I use this validator?
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.
What should I do if my JWT is expired?
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.
How do I use the JWT Validator?
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.
What is the difference between a JWT and a session token?
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.
How are JWT timestamps (iat, exp, nbf) represented?
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.
Can I use the JWT Validator to debug auth issues in my application?
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