JWT Signature Verifier
Cryptographically verify any JWT signature — HS256, RS256, ES256 and more. Runs entirely in your browser.
Paste a JWT and its secret or public key, then click Verify Signature
Or use Load HS256 Sample to try a demo
How to Verify a JWT Signature — 3 Steps
- 1Paste your JWT token. Paste the full JWT token into the input field. The tool automatically decodes the header and detects the signing algorithm (HS256, RS256, ES256, etc.) — you can see it displayed below the input.
- 2Enter the secret or public key. For HMAC tokens (HS256/384/512), type the shared secret string. For RSA or ECDSA tokens (RS256, ES256, etc.), paste the public key in PEM format. You never need the private key to verify a signature.
- 3Click Verify Signature. The browser uses the Web Crypto API to check the signature mathematically. The result shows whether the signature is valid, the expiry status, and all decoded claims with human-readable timestamps.
Decoding vs. Verifying: Why the Difference Matters
Most online JWT tools — including many marketed as “validators” — only decode a JWT. Decoding reads the header and payload by Base64url-decoding the first two segments. It requires no key, takes no security action, and proves nothing about the token's authenticity.
Decoding (what most tools do)
- • Reads header and payload
- • No key required
- • Does not confirm authenticity
- • Cannot detect tampered tokens
- • Useful for inspection only
Verifying (what this tool does)
- • Checks the cryptographic signature
- • Requires the secret or public key
- • Confirms the issuer and integrity
- • Detects any payload tampering
- • Required for security validation
If an attacker modifies a JWT payload (e.g., changes role: "user" to role: "admin"), a decoder will happily show the modified payload. Only verification — checking the signature against the key — will reveal that the token has been tampered with.
Supported Algorithms and What Key to Use
| Algorithm | Type | Key to verify | Common use |
|---|---|---|---|
| HS256 / HS384 / HS512 | HMAC-SHA | Shared secret string | Internal services, single-app tokens |
| RS256 / RS384 / RS512 | RSA PKCS#1v1.5 | RSA public key (PEM) | OAuth 2.0, OpenID Connect, public APIs |
| ES256 / ES384 / ES512 | ECDSA | EC public key (PEM) | Mobile, IoT, performance-sensitive systems |
The algorithm is specified in the JWT header's alg field and is detected automatically. You only need to provide the correct key for that algorithm.
When Developers Verify JWT Signatures
Auth debugging
A request returns 401 Unauthorized. Verify the JWT signature to rule out token tampering or a key mismatch between the issuer and the verifying service.
Key rotation testing
After rotating a signing key, verify that tokens issued with the old key fail and tokens issued with the new key pass — before rolling out to production.
Multi-service auth
When a token passes between services, each service should verify the signature independently. Test that each service uses the correct public key.
Security audits
Check that tokens from third-party providers (Auth0, Cognito, Firebase) use the expected algorithm and key, and that alg:none is never accepted.
Local development
Generate a test token with a known secret and verify it here to confirm your JWT library is signing correctly before writing integration tests.
OIDC / OAuth flows
Verify ID tokens from identity providers by pasting the provider's JWKS public key (converted to PEM). Confirm claims like iss, aud, and sub match expectations.
Security Notes
- ✓A valid signature is not sufficient alone: After verifying the signature, you must also check: exp (not expired), nbf (not before, if present), iss (matches expected issuer), and aud (matches your service). A valid signature from a revoked or expired token should still be rejected.
- ✓Never trust the alg header blindly: Some JWT libraries historically accepted the alg claim from the token header to decide which algorithm to use for verification. This led to attacks where attackers set alg:none or switched from RS256 to HS256 (using the public key as the HMAC secret). Always enforce the expected algorithm on the server side.
- ✓HMAC secrets must be strong: HS256 security depends entirely on the secret being unguessable. Secrets shorter than 32 bytes or derived from common words can be brute-forced offline against a captured JWT. Use cryptographically random secrets of at least 32 bytes.
- ✓This tool uses the browser Web Crypto API: All verification runs via crypto.subtle in your browser. Your token and keys are never transmitted. However, do not paste production secrets or private keys into browser tools as a general principle — use this tool in trusted environments for debugging.
Frequently Asked Questions
What is the difference between decoding and verifying a JWT?
Decoding reads the header and payload by Base64url-decoding the first two segments — anyone can do this without a key. Verifying checks the cryptographic signature using a secret or public key to confirm the token was issued by the expected authority and has not been tampered with. Decoding alone is not sufficient for security.
How do I verify a JWT with HS256?
Paste the JWT token and enter the HMAC secret string used to sign it, then click Verify. The tool re-computes the HMAC-SHA256 signature and compares it to the one in the token. The secret must exactly match the one used by the issuing server.
How do I verify an RS256 JWT?
Paste the JWT and the RSA public key in PEM format (starting with -----BEGIN PUBLIC KEY-----). You do not need the private key — RS256 uses asymmetric signing, so only the public key is needed for verification.
What algorithms does this verifier support?
The verifier supports all standard JWA algorithms: HMAC (HS256, HS384, HS512), RSA PKCS#1 v1.5 (RS256, RS384, RS512), and ECDSA (ES256, ES384, ES512). The algorithm is detected automatically from the JWT header.
The signature is valid but the token is expired — should I accept it?
No. A valid signature means the token was genuinely issued by the expected authority and was not modified, but it does not mean the token is still acceptable. Your server must also check the exp claim and reject expired tokens regardless of signature validity.
Is my JWT token sent to a server when I verify it here?
No. All verification runs in your browser using the Web Crypto API (crypto.subtle). Your token, secret, and public key never leave your device. You can verify this by watching the Network tab in DevTools — no outbound requests are made.
What does alg:none mean and is it dangerous?
A JWT with alg:none has no signature — the third segment is an empty string. This was intentional in the original JWT spec for unsecured use cases, but many JWT libraries had vulnerabilities where they accepted alg:none tokens even when configured to require a signature. Always explicitly reject alg:none tokens in production code unless you have a deliberate reason to allow them.
From the Blog
JWT Decoder Checklist for Authentication Bugs
A quick developer checklist to verify token structure, claims, and expiry during auth issue triage.
What Is a JWT Token? How to Decode It
Understand JWT structure and learn a safe decoding workflow for debugging authentication and authorization flows.
How to Validate JWT Signature Without a Library
Use the Web Crypto API to verify HS256 and RS256 JWT signatures natively in browser and Node.js — no dependencies.
Decode Firebase JWT Tokens — Step by Step
How to decode Firebase ID tokens, inspect claims, debug expiry issues, and understand the token structure.