JWT Verifier Online – Verify JWT Signature, exp, iss & aud

How to use the JWT Verifier

Paste the token into the JWT pane on the left. A leading "Bearer " is removed for you.

Paste the shared secret, PEM public key, X.509 certificate, JWK or JWKS into the right pane.

Optionally fill in Expected issuer, Expected audience and a Clock tolerance in seconds.

Click Verify signature and read the Verification result: the signature status, each claim check, and the decoded header and payload.

What this JWT verifier checks

A decoder only shows what a token says. This jwt verifier checks whether the token is genuine. It recomputes the signature with the key you supply, then checks the time-based claims exp and nbf, and can compare iss and aud with the values your application expects. Use it when an API returns 401 and you need to know whether the token, the key or a claim is the problem.

Keys it accepts

The right-hand pane takes whatever form your key is in:

A shared secret for HS256, HS384 and HS512. Tick Secret is Base64 encoded if the secret is stored as Base64.
A PEM public key (BEGIN PUBLIC KEY) for RS, PS, ES and EdDSA tokens.
An X.509 certificate (BEGIN CERTIFICATE). The public key is taken from the certificate.
A JWK or a whole JWKS, such as the JSON from an identity provider's jwks_uri. The key whose kid matches the token header is used. If the set has a single key, that key is used.
A PEM private key. Only its public part is used for verification.

The algorithm comes from the token's alg header, and the check allows that one algorithm only. A token with alg: "none" is refused outright.

Example

Verifying the sample HS256 token with the secret your-256-bit-secret produces:

✔ Signature VERIFIED (HS256)

Claims:
  • iat  issued 2018-01-18T01:30:22Z

Header:
{
  "alg": "HS256",
  "typ": "JWT"
}

Change a single character of the secret and the first line becomes ✘ Signature NOT verified: the signature does not match this key/secret. The claims, header and payload are still shown, so you can keep debugging.

Options explained

Expected issuer (iss): the result shows a pass or fail line comparing it with the token's iss.
Expected audience (aud): passes when the token's aud equals this value or, for an array, contains it.
Clock tolerance: seconds of leeway for exp and nbf, to allow for small clock differences between servers.

When the signature is valid but a claim fails, the status reads "Signature valid, but some claims fail", so an expired token is not mistaken for a forged one.

Common errors and fixes

"A JWT has three dot-separated parts": the token was cut off when copied, or has extra quotes or whitespace around it.
"This is an encrypted JWE (5 parts)": encrypted tokens must be decrypted first. Only signed JWS tokens can be verified.
"No key with kid … in the JWKS": the provider has probably rotated keys. Fetch the current JWKS and try again.
Signature fails with the right secret: check the Base64 checkbox. A secret that is Base64 text on one side and raw bytes on the other gives a different signature.
exp fails right after issuing: the issuing server's clock is ahead. Add a few seconds of clock tolerance, then fix the clock.

Verifier vs decoder vs encoder

Use the JWT decoder when you only need to read the claims and have no key. Use the JWT encoder to create test tokens. If your provider publishes certificates rather than a JWKS, the certificate decoder shows which key and validity dates you are working with.

Privacy

Verification runs in your browser with the jose library and WebCrypto. The token and key are never uploaded, so you can check tokens from staging systems without sending them to a third party.

Frequently asked questions

Can I verify a JWT without the secret or public key?

No. A signature can only be checked with the matching secret or public key. Without it you can decode and read the token, but you cannot tell whether it has been tampered with.

How do I verify a token from Auth0, Okta, Keycloak or Azure AD?

Open the provider's JWKS URL (usually listed as jwks_uri in /.well-known/openid-configuration), copy the JSON and paste it into the key pane. The verifier picks the key whose kid matches the token header.

Why does the signature pass while the result still shows a failure?

The signature and the claims are checked separately. A token can be genuine but expired, not yet valid, or meant for a different issuer or audience, and your application should reject it in those cases too.

Does the verifier check the nbf and iat claims?

Yes for nbf: the token fails if the current time, plus the clock tolerance, is before it. The iat claim is shown as an issued date but is not treated as a pass or fail, because the JWT standard does not require it to be checked. An exp or nbf value that is not a number of seconds, such as a date string, also fails its check.

Can I verify a JWT with an RSA private key?

Yes. When you paste a private key, the tool drops the private parts and verifies with the public half. For production checks, share only the public key with the services that verify tokens.

JWT Verifier