Skip to main content
Bethemesh
Security & privacy

JWT Signature Verifier

Validate a JSON Web Token: HS256/384/512 signatures with the shared secret, RS, PS or ES 256/384/512 with a JWK, JWKS (selected by kid) or PEM public key, then check the dates with clock tolerance, and the expected issuer and audience.

  • Clipboard

Embed this widget

Customize the result, check the live preview, then copy the code.

Preview

Embed code type

Code to copy

Responsive and automatically resized by Bethemesh.

HS256, HS384, HS512: the shared secret. RS, PS and ES: the public key as a JWK, a JWKS (chosen by kid) or a “BEGIN PUBLIC KEY” PEM.

Optional checks

Pin an algorithm for production-style validation. Automatic mode is useful for inspection only.

Was this tool useful?

How does this tool work?

The JWT verifier tells you whether a token is authentic and still acceptable: it checks its cryptographic signature, then its claims. It is built for back-end developers, OAuth/OpenID Connect integrators and security teams who want to confirm that a token was signed by the right key before looking for a bug elsewhere. To simply read a token’s content, the JWT decoder is enough.

A JWS signature (RFC 7515) covers the Base64URL "header.payload" string; the algorithms are defined in RFC 7518. For HS256, HS384 and HS512, the tool recomputes an HMAC with the shared secret and compares it with the signature. For RS256/384/512 (RSASSA-PKCS1-v1_5), PS256/384/512 (RSASSA-PSS) and ES256/384/512 (ECDSA on P-256, P-384 and P-521), it verifies the signature with the public key through the Web Crypto API; with ECDSA the JWS signature is the raw R‖S concatenation, 64 bytes for ES256, not a DER structure. A token declaring alg: none is always rejected.

The public key can be supplied in three forms: a single JWK (RFC 7517), a JWKS {"keys":[…]} in which the tool picks the key whose kid matches the header, or a "BEGIN PUBLIC KEY" PEM (SubjectPublicKeyInfo). For validation close to production, select an Expected algorithm instead of leaving the tool in Automatic mode: this prevents a token from choosing a different accepted algorithm through its own alg header. Automatic mode remains useful for inspection. Once the signature is valid, the tool checks exp and nbf with an adjustable clock tolerance (for example 60 seconds to absorb clock drift between servers), then the expected iss issuer and aud audience if you provide them. The result reads "valid" or "invalid" with the exact reason: wrong signature, kid not found, expired, not yet valid, unexpected issuer or audience.

How to use this tool

  1. Paste the JWT

    Paste the full token. The algorithm declared in its header determines the expected key type: a secret for HS*, a public key for RS*, PS* and ES*.

  2. Provide the key

    Enter the shared secret, or paste a public JWK, a whole JWKS or a PUBLIC KEY PEM. With a JWKS, the key is picked automatically from the kid.

  3. Set the checks and read the verdict

    Adjust the clock tolerance, add the expected issuer and audience if needed, then read the valid or invalid result and its reason.

Use cases

Verify an Auth0, Keycloak or Entra ID token

Fetch the JWKS published at your provider’s jwks_uri (for example /.well-known/jwks.json), paste it with the token and confirm that the RS256 signature matches a published key.

Debug a key rotation

After a rotation your API rejects tokens: check whether the header’s kid still exists in the JWKS or whether the token was signed with a retired key.

Check an HS256 secret between two services

One microservice rejects tokens issued by another: test the shared secret and the expected audience to find out whether the problem is the key or the claims.

Examples

Inspect a test JWT

Input

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; Expected algorithm: HS256; Secret or public key: incorrect-secret

Result

Token rejected: Invalid signature: the token was altered or the key does not match. Token details: Subject 1234567890, Issued 1516239022 (iat), no expiry date (no exp claim).

Tips and best practices

  • If you only have a certificate (BEGIN CERTIFICATE), extract its public key first, for example with openssl x509 -pubkey -noout, because the tool expects a PUBLIC KEY PEM.
  • An HS256 secret given in Base64 by a provider must be used as exactly the same bytes that were used to sign: the Base64 string and its decoded form do not produce the same signature.
  • Keep the clock tolerance short (tens of seconds to a few minutes): a very large value amounts to accepting expired tokens.

Sources and references

Frequently asked questions

What is the difference between decoding and verifying a JWT?

Decoding reads the Base64URL-encoded header and payload without any key. Verifying recomputes or checks the signature with the issuer’s secret or public key, then validates exp, nbf, iss and aud. Only verification proves the token was not forged or modified.

Which key do I need to verify an RS256 or HS256 JWT?

HS256 is symmetric: the same secret signs and verifies. RS256, PS256 and ES256 are asymmetric: the issuer signs with its private key and you verify with the public key, usually published in a JWKS. You never need the private key to verify.

What is the kid in a JWT header for?

The kid (key ID) tells which key from the JWKS signed the token, which lets the issuer publish several keys during a rotation. When you paste a JWKS, the tool selects the key with the matching kid. If no kid matches, the key was probably retired or the JWKS does not come from the right issuer.

Why is my JWT signature invalid?

The most common causes are the wrong key (another environment, a retired key), a badly encoded secret, a modified or truncated token, or a key that does not match the declared algorithm. On the server, always enforce the expected algorithm instead of trusting the alg field, to prevent the algorithm confusion attacks described in RFC 8725.

What is clock tolerance (leeway)?

It is a margin added when checking exp and nbf to compensate for a small difference between the issuer’s clock and the verifier’s. With 60 seconds of tolerance, a token that expired 30 seconds ago is still accepted. Most libraries use a value between 0 and 5 minutes.

Can I paste a key or secret into this tool?

A public key is not secret and can be pasted safely. An HMAC secret is: here verification runs in your browser with the Web Crypto API and nothing is transmitted, but still avoid using a production secret on a shared computer.

Recommended workflow

Continue your processing

Discover tools that naturally fit before, after, or alongside this one.

Use before

JWT Decoder

Decode a JWT to read its header, payload, claims and expiration dates.

Security & privacyFeaturedUse this tool

Works well with

JWK / JWKS Inspector

Inspect a JWK or JWKS: kid, kty, alg, use, RFC 7638 thumbprint and a warning when private key material is exposed.

Security & privacyUse this tool

JWT Encoder

Create and sign an HS256, HS384 or HS512 JWT from a header, a JSON payload and a secret.

Security & privacyUse this tool

Read next