Racira Developers

JWT RS256 Verifier

Verify RS256-signed JWTs.

Input
Output
Enter input to see results
Runs entirely in your browser. No data leaves your device.

More in Security

Hash Generator

Generate hashes from text.

Bcrypt Generator

Create bcrypt password hashes.

UUID Generator

Generate UUIDs and ULIDs.

Password Strength Checker

Measure password strength.

JWT Decoder

Inspect JWT payloads.

JWT Generator

Sign and create JWTs.

JWT Expiry Checker

Check JWT expiration.

JWT Visualizer

Visualize JWT structure.

What the JWT RS256 Verifier Does

The JWT RS256 Verifier prepares an RSA-signed token for verification and shows you exactly what that verification will consume. Paste a token and run the transform: the tool decodes the header, checks that its alg really is RS256, decodes the payload to pretty-printed JSON, and prints the signature segment as its full Base64Url string. The output is a four-part report — header, payload, signature, and the note that public-key verification is the remaining step.
The honest headline: this tool inspects, it does not perform the RSA maths. Genuine RS256 verification needs the issuer's RSA public key — the check is a modular-exponentiation comparison that only means something with the right key, and this page does not ask you to paste one. What it gives you instead is everything up to that point: confirmation that the token claims RS256 (mismatched algorithms are a classic misconfiguration), the readable claims, and the exact signature bytes a verifier would check.
Why inspect rather than verify? Because the decision that matters most about an RS256 token is often structural: is this actually an RS256 token, is the payload what the issuer says it is, does the key-id in the header match the key we have on file. Those questions are answerable by eye. The cryptographic check belongs in your service, where the public key lives and the trust decision is enforceable.

How RS256 Works Differently from HS256

RS256 is the asymmetric counterpart to HS256, and the difference drives everything about how each is verified. HS256 is symmetric: one shared secret both creates and checks the signature, so every verifier is also a signer. RS256 splits those powers: the identity provider signs with an RSA private key it never shares, and anyone holding the corresponding public key can verify — without gaining any signing ability.
That split is why RS256 dominates distributed systems. Your API gateway, three microservices, and a partner integration can all verify tokens against a public key (often fetched from a JWKS endpoint) while the private key stays on the auth server. With HS256, every one of those verifiers would hold the shared secret, and any compromise would let the attacker mint tokens at will. Asymmetry trades a little speed for a much smaller blast radius.
Mechanically, the signature is computed as RSA's PKCS#1 v1.5 signature over SHA-256(header.payload) — the RS256 identifier in the JWA spec fixes both the hash and the padding. The result is 256 bytes for a 2048-bit key, which Base64Url-encodes to 342 characters: the first visual difference from HS256's 43. The verification maths itself belongs to whichever system holds the public key..
One practical consequence shows up constantly in debugging: an RS256 token pasted into an HS256 verifier (or vice versa) fails even with the correct key material, because the algorithms are different primitives. The header's alg claim is the arbiter — which is why this tool's first act is to read it and tell you what the token says it is.

Using the JWT RS256 Verifier

  1. Step 1 — Paste the complete token. All three dot-separated segments. RS256 tokens are visibly longer than HS256 ones — that is the 342-character signature, not an error.
  2. Step 2 — Run the transform. No options, no key field. The tool reads the token's own declarations.
  3. Step 3 — Check the algorithm line first. If the header says anything other than RS256, the tool reports it immediately — Algorithm is HS256, not RS256 — along with the decoded structure. A token signed HS256 but expected RS256 will fail verification no matter how correct the keys are.
  4. Step 4 — Read the payload and signature sections. The payload's claims are now readable, and the signature section shows the exact Base64Url string your verification step will consume. Copy the token itself when you move on — never retype the signature.
  5. Step 5 — Verify against the public key in your service. The report ends with the note that verification requires the matching public key. In practice that means your backend (or a standard library pointed at the issuer's JWKS endpoint) performs the actual check. This tool tells you what will be checked; your system decides whether it passes.

Common Use Cases

Pre-verifying tokens from an identity provider. Before wiring your service to a new IdP, paste one of its tokens here: confirm the algorithm is what their docs claim, see which claims arrive, and note the signature length. Most integration surprises are visible in that first look.
Diagnosing algorithm mismatches. "Invalid signature" errors where the key is definitely correct are usually an algorithm mismatch — the token says HS256, your verifier assumes RS256, or the reverse. The tool's algorithm check surfaces that in seconds.
Inspecting JWKS-rotated tokens. After a key rotation, tokens carry a new kid in the header. Pasting a failing token shows whether its header and claims are healthy and the failure is purely on the key side.

Worked Example

Paste this token — header and payload are real RS256-shaped examples, and the signature segment is the full 342-character length an RSA-2048 signature produces:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.[342-character signature]
The report comes back in four parts:
Header:
{ "alg": "RS256", "typ": "JWT" }

Payload:
{ "sub": "1234567890", "name": "Jane Doe", "iat": 1516239022 }

Signature (b64url):
[the 342-character string]

Note: RS256 verification requires the matching public key, paste it to verify.
Read it in order. The header confirms RS256 — so whatever verification you point this token at must use RSA with SHA-256. The payload's claims are fully readable: subject, name, issued-at. The signature section is display-only: 342 characters of 256-byte RSA output, meaningful only to a verifier holding the matching public key. The closing note is the tool being honest about where its job ends.
Now the instructive failure: paste an HS256 token instead. The first line of the report changes — Algorithm is HS256, not RS256 — and the info line flags that signature verification would need different key material. The rest of the report still renders, because a wrong-algorithm token is still a readable token. Structural inspection and cryptographic trust are separate axes, and this tool is explicit about which one it operates on.

Tips and Common Mistakes

  1. "Verifier" here means inspection, not RSA verification. The tool never performs the signature check — it cannot, without a public key. Treat its output as everything-you-need-to-verify, not verification itself.
  2. Check alg before blaming keys. The most common RS256 debugging dead-end is an HS256 token arriving at an RSA verifier. One glance at the algorithm line usually saves an hour of key archaeology.
  3. Signature length is a fingerprint. 342 characters for RSA-2048, 43 for HS256. If the signature segment is the wrong length for the claimed algorithm, the token was truncated or mislabeled somewhere upstream.
  4. Never hand-verify a signature from the display. Copy the whole token to your verification path. Retyping even one Base64Url character breaks the check, and URL-safe characters (-, _) are easy to mistype after a clipboard detour.
  5. Public keys come from the issuer, not the token. The token's header may carry a kid hinting at which key to use, but the key material itself must come from your trusted source — the IdP's JWKS endpoint or your configuration. A token that carries its own "public key" in a claim is describing itself, and self-description is exactly what signatures exist to test.
  6. Local-only still applies. The tool transmits nothing and stores nothing, but the habit stands: prefer test or expired tokens, and treat live identity-provider tokens as sensitive wherever you paste them.

Frequently Asked Questions

Does this tool actually verify the RSA signature?

No — and the distinction is the tool's design. Real RS256 verification requires the issuer's public key and the RSA maths over the signature bytes. This tool decodes the header, confirms the algorithm, shows the claims, and displays the signature — everything verification consumes — and states plainly that the key check is the remaining step. Your service (or a library pointed at the issuer's JWKS) performs it.

Why won't it let me paste a public key?

Because a browser-side verification would give false confidence in the one place trust matters. A page that accepted any pasted key would "verify" tokens against attacker-supplied keys — precisely the confusion the tool avoids by not playing.

The report says my token is HS256 — is that a problem?

Only relative to your expectation. The tool reports what the header claims; whether that algorithm is acceptable is your system's policy. If your infrastructure is RS256 end-to-end, an HS256 token arriving is a misconfiguration upstream (or a forgery attempt probing for algorithm confusion), and it should fail verification regardless.

Why is my RS256 signature so much longer than an HS256 one?

The signature length equals the RSA key size: 2048-bit keys produce 256-byte signatures, which Base64Url-encode to 342 characters. HS256's SHA-256 digest is fixed at 32 bytes (43 characters). The asymmetry in size mirrors the asymmetry in the crypto — RSA signatures carry the modulus-sized output of the private-key operation, while HMACs are bare hashes.

What is a kid and should I check it here?

The kid (key ID) header claim tells a verifier which key in the issuer's set signed the token — essential when providers rotate keys. The tool shows the decoded header, so the kid is visible alongside alg. Checking it here is useful diagnostics (is the token even claiming a known key?), but the enforcement — reject unknown kids, prevent key-confusion attacks — belongs in your verifier.

Related Tools

JWT Decoder for the same inspection with algorithm/expiry info in JSON form; JWT HS256 Verifier for the symmetric case, where browser-side verification is possible because the secret is a shared string; RSA Key Generator to see the keypair shape behind RS256; JWT Validator for structural and temporal health; and Hash Comparison Tool for the constant-time-compare pattern that underlies signature checks generally.