JWT Verifier

Inspect auth headers and token data in your browser. No input is sent to a server. Use it for first-pass checks on expiry, claims, and schemes.

 

JWKS status

Time checks

exp (expiration)

iat (issued at)

nbf (not before)

Status

Runs in your browser. No input is sent to a server. Use this as a first-pass diagnostic step.

How to use

Paste a JWT and click “Verify”. Match key type to alg (shared/public/JWKS), then review time-check results after signature success.

Notes (this tool)

  • HS uses a shared secret; RS/ES verify with public keys. Pasting private keys is not recommended.
  • A valid signature is not enough; business-claim checks (iss/aud/sub) are still required.
  • JWKS fetching depends on CORS. If it fails, check URL reachability and CORS policy.

About this page

What does this tool do?

Verify JWT signatures and pretty-print header/payload. It can also check exp/nbf/iat time claims.

Supports HS/RS/ES algorithms with manual keys or JWKS.

Use it when you need to confirm a JWT is authentic (not tampered with). For decode-only, use JWT Decoder.

Supported algorithms (HS/RS/ES)

JWT signature algorithms are specified by the header alg. This tool supports common JWS algorithms (HMAC/RSA/ECDSA).

  • HS256/384/512: verify with a shared secret
  • RS256/384/512: verify with an RSA public key (PEM/SPKI)
  • ES256/384/512: verify with an ECDSA public key (PEM/SPKI)

Providing keys (manual / JWKS)

For HS, provide the shared secret. For RS/ES, provide a public key (PEM). A private key is not required.

With a JWKS URL, the tool selects a JWK matching kid (or auto-selects if only one key exists).

JWKS notes (CORS)

JWKS is fetched directly by your browser. Whether it works depends on the server’s CORS configuration.

Debugging workflow (recommended)

  • Confirm alg and kid in header
  • Choose proper key type for alg (HS secret or RS/ES public key)
  • Evaluate exp/nbf/iat after signature verification passes
  • On failure, check kid mismatch, key-type mismatch, clock skew, and tampering in order

Recommendations (practical)

  • Pin allowed algorithms and reject unexpected ones
  • Even with valid signatures, always verify business claims (iss/aud/sub)
  • Assume key rotation in JWKS and enforce clear kid handling

What this tool does

  • Signature verification (HS256/384/512, RS256/384/512, ES256/384/512)
  • Key selection via JWKS (kid)
  • exp/nbf/iat checks with leeway

Time checks (exp/nbf/iat)

exp/nbf/iat are typically Unix time (seconds). If clocks can drift, set a leeway value.

  • exp: expiration (expired when now > exp + leeway)
  • nbf: not before (invalid when now + leeway < nbf)
  • iat: detect tokens issued in the future (optional)

Common pitfalls

  • Trying to verify RS tokens using HS shared secrets
  • JWKS fetch succeeds but no key matches kid
  • exp/nbf checks fail due to clock skew only
  • Skipping aud/iss validation after signature success

Operational notes

  • Result output alone is not enough for trust decisions. Always validate signatures and issuer.
  • Clock skew and environment differences affect reproducibility, so record test time and settings.

Referenced specs

  • RFC 7519 (JWT)
  • RFC 7515 (JWS)
  • JWKS (RFC 7517)
  • RFC 7518 (JWA)
  • RFC 8725 (JWT BCP)
  • Web Crypto API (browser-side verification)

FAQ

What is the difference between HS/RS/ES?

HS uses a shared secret (HMAC). RS/ES use public keys (RSA/ECDSA).

What about alg=none?

This tool treats it as invalid.

Do I need to paste a private key?

No. RS/ES can be verified with a public key. Avoid pasting private keys.

Notes (security)

  • Handle secrets/tokens carefully (screen sharing, log pasting, etc.).
  • Using JWKS will make a browser request to the URL.
  • Even if signature is OK, app-specific checks like aud/iss may still be required.

References

  1. RFC 7519 (JWT)
  2. RFC 7515 (JWS)
  3. RFC 7517 (JWK / JWKS)
  4. RFC 7518 (JWA)
  5. RFC 8725 (JWT BCP)

Page-specific case studies

This page focuses on signature validation and key, algorithm, and claim consistency.

  • Check if alg matches your intended HS, RS, or ES profile.
  • Verify kid alignment with the public key set.
  • Validate issuer and audience constraints.

Page-specific implementation checklist

  • Explicitly whitelist accepted algorithms.
  • Provide overlap windows during key rotation.
  • Log reason codes for verification failures.
  • Separate token verification from authorization logic.

These links are generated from site_map rules in recommended diagnostic order.

  1. JWT 401/403 Diagnostic Playbook — Separate 401 and 403 using Authorization, WWW-Authenticate, claims, and signature checks
  2. JWT Decoder vs Verifier — Clarify decode vs signature verification roles and connect to 401/403 troubleshooting flow
  3. WWW-Authenticate Inspect — Parse WWW-Authenticate challenges
  4. JWT Clock Skew Check — Detect timestamp skew across iat/nbf/exp
  5. Authorization Inspect — Parse Authorization header formats
  6. JWT TTL Check — Calculate validity window and remaining TTL from exp/iat/nbf
  7. OAuth Bearer Diagnostic — Diagnose consistency between Bearer and WWW-Authenticate
  8. JWT 401/403 Troubleshooting — Troubleshoot 401/403 auth failures from headers and JWT claims

Auth

Trace auth failures across Bearer, WWW-Authenticate, and JWT

Example

eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJleHAiOjE3MDAwMDAwMDB9.signature