JWT Signature Verifier (RS256/ES256, Public Key Verification)
A developer tool that verifies JWTs (JSON Web Tokens) signed with RS256 or ES256 using an SPKI-format public key (PEM), right in your browser. It also decodes the header/payload and checks the expiry claim. Nothing you enter is sent to a server; everything runs client-side.
Supported signature algorithms
| Algorithm | Key type | Hash function | Description |
|---|---|---|---|
| RS256 | RSA (RSASSA-PKCS1-v1_5) | SHA-256 | Signature using RSA public-key cryptography. The default algorithm for ID tokens issued by major OAuth 2.0/OpenID Connect providers such as Google, Auth0, and Okta. |
| ES256 | ECDSA (P-256 curve) | SHA-256 | Signature using elliptic-curve cryptography, offering equivalent security to RSA with shorter keys and signatures — increasingly popular for mobile apps and IoT devices. |
Verifying a JWT signature with a public key
This tool verifies a JWT signed with RS256 or ES256 against a PEM public key in SPKI form. It shows the decoded header and payload alongside the expiry. Everything you enter is processed inside the browser and is never sent elsewhere.
**What deserves emphasis is that a valid signature and a valid token are two different things.** A signature that verifies proves only that the contents have not been rewritten since they were issued. Real authentication additionally requires checking that `exp` for the expiry, `nbf` for the not-before time, `iss` for the issuer and `aud` for the intended audience all match what you expect. **The other well-known pitfall in implementation is letting the token's own header decide which algorithm to verify with.** Unless the server fixes the acceptable `alg` in advance, it leaves the choice open to an attacker.
How to verify
- Paste in the JWT It is a string of three parts separated by dots.
- Paste the public key in PEM form **It is the public key you need, not the private one.** RS256 takes an RSA key and ES256 a key on the P-256 curve.
- Verify the signature The tool reports whether the key and the signature agree.
- Check the decoded contents and the expiry **A token whose signature verifies must still not be used once it has expired.** Look at both.
Tips for getting more out of it
- The public key must be in PEM format (SPKI, starting with "-----BEGIN PUBLIC KEY-----"). Pasting a private key file or a certificate (.crt) directly will not work.
- The verification algorithm is chosen automatically based on the
algfield in the JWT header (RS256 or ES256) — no manual selection needed. - The tool also checks the payload's
expclaim alongside signature verification and warns if the token has expired. A valid signature does not mean the token should still be accepted. - This tool only supports RS256 and ES256. To check an HS256-signed JWT, use the companion JWT Encoder to re-sign with the same shared secret and compare the result.
- The public key you use for verification is not secret, so it is fine to paste one obtained from an identity provider's public endpoint (such as a JWKS).
Where it comes in useful
Inspecting the contents of an ID token
A token issued by an identity provider can be checked against its public key.
Telling a wrong key from a broken signature
**When verification fails, you can establish locally which of the two is at fault.**
Testing a key rotation
Trying the old and new keys in turn confirms that the changeover will play out as planned.
Tracing the cause of a fault
Faced with a report that authentication is failing, you can first establish whether the token itself is to blame.
Terms in JWT verification
- RS256
- A signature scheme using an RSA key with SHA-256. **Signing takes the private key, verification the public one.**
- ES256
- A signature scheme using the P-256 curve with SHA-256. Both key and signature come out shorter than with RSA.
- SPKI
- The standard form in which a public key is carried. In PEM it opens with `-----BEGIN PUBLIC KEY-----`.
- Exp
- The claim giving the expiry. **However sound the signature, a token past this moment must not be accepted.**
- Nbf
- The claim giving the moment from which the token becomes usable. Before it, the token is not yet in force.
- Algorithm confusion
- **A weakness in implementations that verify with whatever algorithm the token's header names.** The accepted scheme must be fixed on the verifying side.
Frequently Asked Questions
Side Note — HMAC vs. public-key signatures: what is the difference?
JWT signature schemes fall into two broad families: shared-secret (HMAC, e.g. HS256) and public-key (RSA/ECDSA, e.g. RS256 and ES256). With a shared secret, both the signer and the verifier must hold the same secret string; with public-key cryptography, only the signer holds a private key, while anyone can verify using the publicly available key. This distinction shapes how APIs are designed. The companion JWT Encoder (HS256) suits cases where the same server both issues and verifies tokens, while RS256/ES256 — the focus of this tool — suit cases where the issuer and the verifier belong to different organizations or servers entirely.
In practice, ID tokens issued by major identity providers such as Google OAuth 2.0, OpenID Connect, Auth0, and Okta are almost always signed with RS256 (with ES256 often available as an alternative). This lets the identity provider hold the only private key while any number of client applications verify tokens using just the public key — eliminating the need to distribute a secret to every client and confining the risk of key leakage to a single point at the signer.
RS256 and ES256 both hash with SHA-256, but differ in the underlying cryptography. RS256 uses RSA (typically 2048-bit or longer keys), which tends to produce larger signatures but benefits from mature, widely supported libraries. ES256 uses elliptic-curve cryptography (P-256), achieving comparable security with much shorter keys and signatures — a growing favorite for mobile environments and APIs where payload size matters.