Verifier & Claims Inspector
JWT Validator
Validate a JSON Web Token's structure, signing algorithm, cryptographic signature, expiration, and configured claims directly in your browser.
About JWT validation and common questions
What does JWT validation check?
Overview
JWT validation confirms more than whether a token can be decoded. A complete validation checks the token structure, the declared signing algorithm, the cryptographic signature, time-based claims, and any issuer or audience rules required by the application.
The header and payload of a signed JWT are readable Base64URL-encoded JSON. Reading those values does not prove that they are authentic. Authenticity comes from verifying the signature with the correct secret or public key.
Where it is used
- API access tokens and bearer-token debugging
- OpenID Connect ID token inspection
- Authentication middleware configuration
- Service-to-service authorization troubleshooting
- Issuer, audience, and expiration diagnostics
- Testing token validation rules during development
Key facts
- Decoding a JWT is not the same as validating it.
- HMAC algorithms use the same secret for signing and verification.
- RSA and ECDSA algorithms use a private key to sign and a public key to verify.
- The accepted algorithm should be restricted by the application, not trusted only because the token declares it.
- The exp and nbf claims are evaluated against the current time and configured clock tolerance.
- Issuer and audience checks only pass when expected values are explicitly configured.
Examples
Valid signature and claims
The signature matches, the token is active, and every configured issuer, audience, and subject rule passes.
HS256 token plus the correct secretJWT is validSignature mismatch
The token can still be decoded, but its authenticity cannot be established with the supplied key.
RS256 token plus an unrelated public keySignature verification failedExpired token
Cryptographic verification and claim acceptance are separate results. A correctly signed token may still be unusable.
Correct signature with exp in the pastSignature is valid, but claims failedAudience mismatch
Audience validation prevents a token intended for one service from being accepted by another service.
Expected API audience differs from audAudience check failedCommon mistakes
- Treating successfully decoded JSON as proof that the JWT is authentic.
- Accepting whichever algorithm is declared in the token without an application-side allowlist.
- Using a private signing key when only a public verification key should be shared.
- Skipping issuer or audience validation for tokens received from external systems.
- Ignoring exp, nbf, or clock differences between systems.
- Pasting production tokens or secrets into tools that send input to a server or analytics service.
Limitations
- This page validates compact signed JWTs and does not decrypt JWE tokens.
- Remote JWKS retrieval and OpenID Connect discovery are intentionally not included in this version.
- PEM validation expects an SPKI PUBLIC KEY block rather than a certificate or PKCS#1 RSA PUBLIC KEY block.
- A successful result confirms the configured checks only. Application-specific authorization rules may still reject the token.
Technical details
Signature verification
The signature covers the Base64URL-encoded header and payload joined by a period.
HMAC verification uses a shared secret. RSA, RSA-PSS, and ECDSA verification use a public key.
Registered time claims
exp defines when the token expires, nbf defines when it becomes active, and iat records when it was issued.
Clock tolerance can account for small time differences between the token issuer and the validating system.
Expected claims
Issuer, audience, and subject checks require an expected value supplied by the validating application.
A missing expectation is reported as not checked rather than passed.
Frequently asked questions
Is a JWT secure because its payload looks encoded?
No. The header and payload are normally readable. A signed JWT protects integrity and authenticity, not confidentiality.
What is the difference between decoding and validating?
Decoding reads the header and payload. Validation also verifies the signature and applies time, issuer, audience, subject, and algorithm rules.
Should I use a secret or a public key?
Use a secret for HS256, HS384, or HS512. Use a public key for RSA, RSA-PSS, or ECDSA algorithms. Never expose an asymmetric private signing key just to validate a token.
Why can a token have a valid signature but still fail?
A valid signature only proves that the signed data matches the supplied key. The token can still be expired, not active yet, issued by the wrong issuer, or intended for another audience.
What does clock tolerance do?
It allows a small difference between the browser clock and the issuer clock when checking exp, nbf, and future iat values. Keep it as small as operationally practical.
Are my token and key uploaded?
This implementation uses the browser Web Crypto API and processes validation locally. Do not add token contents, secrets, or key values to URLs, analytics events, logs, or remote error reports.
Token
JSON Web Token
Cryptography
Verification material
Validation uses the browser Web Crypto API. Do not send token, secret, or key values to analytics, URLs, logs, or remote error reports.
Additional validation rulesIssuer, audience, subject, algorithm, and clock tolerance
Guide
How to use the JWT Validator
Supply a compact signed JWT and the correct verification material, then review each structural, signature, time, and expected-claim result.
Paste the signed JWT
Enter a compact token containing three dot-separated sections. The tool reads the header to detect the declared algorithm, type, and optional key ID.
Provide verification material
HMAC algorithms require the shared secret. RSA, RSA-PSS, and ECDSA algorithms require the corresponding public key as SPKI PEM or JWK.
Restrict the algorithm
Keep validation restricted to the algorithm expected by your application. A token should not be trusted merely because its own header declares an algorithm.
Configure expected claims
Add issuer, audience, or subject values when your application requires them. An omitted expectation is reported as not checked rather than passed.
Review signature and time checks
The report separates signature verification from expiration, not-before, and issued-at diagnostics so a correctly signed but unusable token is clearly identified.
Protect sensitive values
Keep validation local. Never place production tokens, shared secrets, or private keys in URLs, analytics events, application logs, screenshots, or remote error reports.