What is the RS256 vs HS256 algorithm confusion attack?

The algorithm confusion attack (also called the RS256 → HS256 swap) exploits libraries that pick the verification algorithm from the token header instead of a fixed allowlist. Here is how it works: an attacker takes a valid RS256 token (verified with a public key) and rewrites the header's alg to HS256 . They then re-sign the token with HMAC-SHA256 using the RSA public key itself as the HMAC secret. If your server — told to use HS256 — verifies with the RSA public key as the shared secret, the forged token passes signature checks, and the attacker can then put any claims they want in the payload (for example, role: admin ). Defenses: Allowlist algorithms — never accept alg from the header; pin it to a fixed list (e.g. algorithms: ['RS256'] in jsonwebtoken/PyJWT, or Validation::new(Algorithm::RS256) in Rust). Never use a public key as an HMAC secret — the public key is, by definition, public, so anyone can forge an HMAC signature with it. Reject none and mixed-type keys — also disable the alg: none path, which lets attackers omit the signature entirely. This tool supports both families so you can reproduce the attack: encode the same claims as HS256 using the RSA public key as the secret, then watch the checklist flag the token as valid when the verifier accepts HS256.

What algorithms does this tool support, and when should I use each?

This tool supports the major JWT signing algorithm families — HMAC (HS256/384/512), RSA PKCS#1 v1.5 (RS256/384/512), RSA-PSS (PS256/384/512), and ECDSA (ES256/384/512) — plus alg: none for testing signature-stripping attacks: HS256 / HS384 / HS512 — HMAC with SHA-256, SHA-384, or SHA-512. One shared secret both signs and verifies. Fast and simple, but the secret must be shared securely with every verifier. Ideal when signer and verifier are the same system or a small, trusted group. RS256 / RS384 / RS512 — RSA PKCS#1 v1.5 with SHA-256, SHA-384, or SHA-512. A private key signs; anyone with the public key verifies. RS256 is the default for most OIDC providers (Google, Auth0, Keycloak). Use it when many services must verify tokens without sharing a secret. PS256 / PS384 / PS512 — RSA-PSS, the randomized RSA variant. Same trust model as RS*, with signatures salted per message for stronger security properties. ES256 / ES384 / ES512 — ECDSA over P-256, P-384, or P-521. Same asymmetric trust model as RS*, but with compact signatures (64/96/132 bytes) and very fast verification. Great for high-traffic APIs and constrained clients. Choosing: single service → HS256; multi-service / third-party verification → RS256 or ES256; minimal bandwidth or CPU → ES256. The security of an HMAC depends on the secret's entropy , not the hash size — HS384 and HS512 are not inherently stronger than HS256.

How does the expiry visualization work?

In Decode / Verify , once the payload is parsed the tool updates once per second: exp — a live countdown (e.g. Expires in 1h 14m 05s ) plus a progress bar showing how much of the token's lifetime has elapsed (measured from iat or nbf to exp ). The bar shifts green → amber → red as it approaches expiry. nbf — a countdown until the token becomes valid if it is in the future, otherwise it reports how long it has been valid. The countdown is computed from the current time on your device, so it is an approximation for inspection — your server's clock is the source of truth for actual validation.

What claims does the validation checklist check?

The checklist inspects the decoded payload and reports, per claim, whether it is present and what state it is in: exp — present, and expired or expiring in X nbf — present, and not-yet-valid or active iss — present, and whether it matches the expected issuer you entered aud — present, and whether it includes the expected audience you entered iat — present, and how long ago the token was issued A missing check just means the claim is absent from the payload — which is itself useful to know, since most production verifiers require exp , iss , and aud .

How is this different from jwt.io?

Both tools decode JWTs entirely in your browser — BetterPass just pairs that with a few extras. A whole token toolkit — PASETO, Opaque, SAML, and OIDC tools plus a built-in JWT-vs-PASETO comparison, so you can evaluate and debug every token format in one place. Educational depth — production best practices, glossary-level FAQs, and plain-language explainers on claims and algorithms. No account, no tracking — tokens and secrets never leave your device, and nothing is stored or logged. Free and open-ended — no sign-up, no usage limits. For niche algorithms or ASN.1 parsing, dedicated services may go further — but for everyday JWT encode/decode/verify and learning, this tool covers the workflow locally.

JWT Encode/Decode Online

Build and debug JWTs without a server — sign with HS256/384/512, RS256/384/512, PS256/384/512, or ES256/384/512. Verify tokens with JWKS-based key matching, live expiry countdowns, and a claim validation checklist.

Generated Token

Result

Input

Algorithm

Insert a claim template (replaces the payload).

Header (JSON)

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (JSON)

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1893456000,
  "exp": 1893542400
}

Secret (for HS256)

Leave empty to preview the token with a signature placeholder.

What is JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It has three dot-separated parts: a header (the algorithm and type), a payload (the claims), and a signature that proves the header and payload have not been tampered with. JWTs are widely used in modern web applications to handle authentication and authorization efficiently without constant database lookups. If you work with identity providers, see our OIDC ID Token tool — it covers the RS256/JWKS side of JWT verification. For a security-first alternative, try our PASETO tool, or for server-managed sessions, our opaque token generator.

This tool goes beyond a basic encoder/decoder:

Multiple algorithms — HS256/HS384/HS512 (symmetric HMAC), RS256/RS384/RS512 (RSA PKCS#1 v1.5), PS256/PS384/PS512 (RSA-PSS), and ES256/ES384/ES512 (ECDSA). All signature work runs in your browser via the Web Crypto API.

JWKS verification — point at an issuer's jwks.json URL and the tool auto-matches the token's kid, or paste a JWK / PEM public key directly.

Claim validation checklist — a live view of exp, nbf, iss, aud, and iat: present or absent, expired or not, and matched against expected values.

Expiry visualization — a ticking countdown and progress bar for the token's lifetime (from iat/nbf to exp).

Claim templates — common iss/sub/aud payload shapes with live timestamps.

The payload is encoded, not encrypted — anyone can read it. Never put secrets in a JWT.

Zero-Server Tool Data Guarantee

All encoding, decoding, and signature verification happens entirely in your browser using the Web Crypto API. Your tokens, secrets, keys, and any JWKS documents you fetch are never transmitted to or stored by this site. The only network request is the optional JWKS URL you choose to fetch, which goes directly from your browser to that issuer over HTTPS.

How to Use

Choose a mode

Use Encode to build a new token or Decode / Verify to inspect and check an existing one.

Pick an algorithm and key

For HS256/384/512 enter a shared secret. For asymmetric algorithms (RS*/PS*/ES*) paste a PKCS#8 private key or private JWK to sign, and a JWK / PEM public key or JWKS URL to verify.

Use claim templates

Insert common iss/sub/aud payload shapes, then set exp to now + 15 minutes or now + 1 hour with one click.

Read the checklist

In Decode / Verify, watch the live exp/nbf countdown and progress bar, and check whether iss and aud match the expected values.

Common Use Cases

API Auth Testing

Mint HS256/HS384/HS512 tokens with arbitrary claims to test how your API validates expiry, issuer, and audience.

OIDC / SSO Debugging

Fetch an identity provider's JWKS URL and verify a real RS256 or ES256 ID Token, matching the signing key by kid.

Signature Verification

Check whether a token's signature is genuinely valid — not just decodable — using a JWK, PEM public key, or JWKS endpoint.

Security Education

Demonstrate the RS256→HS256 algorithm-confusion attack and why allowlisting algorithms is non-negotiable.

API Authentication & Authorization

The most common use. After a user logs in, the server issues a JWT. This token is then sent with every subsequent API request to prove the user's identity and permissions.

Single Sign-On (SSO)

When a user logs into one service, they can seamlessly access other related services within the same ecosystem without re-authenticating, all powered by shared JWTs.

Information Exchange

Securely transmitting information between trusted parties. For instance, a payment gateway might use a JWT to confirm a transaction's integrity back to your application.

OAuth 2.0

Often used as the format for access tokens in OAuth 2.0 flows, allowing clients to access protected resources on behalf of a user.

Implementation Examples

JavaScriptNode.js (jsonwebtoken) — HS256/384/512

// Install: npm install jsonwebtoken
const jwt = require('jsonwebtoken');

const payload = { userId: '123', role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 };
const secret = 'your-super-secret-key'; // Keep this safe!

// Signing (pick HS256 / HS384 / HS512)
const token = jwt.sign(payload, secret, { algorithm: 'HS256' });
console.log('Generated JWT:', token);

// Verification — ALWAYS pin the algorithm list
try {
  const decoded = jwt.verify(token, secret, { algorithms: ['HS256'] });
  console.log('Decoded Payload:', decoded);
} catch (err) {
  console.error('JWT Verification Failed:', err.message);
}

JWT vs. PASETO vs. Traditional Session Tokens

Feature	JWT (JSON Web Token)	PASETO (Platform-Agnostic Security Token)	Traditional Session Tokens (Cookies)
Design Philosophy	Flexible, widely adopted, claims in payload.	Security-first, explicit design, no algorithm agility.	Server-side state, opaque tokens (pointers).
Mutability	Payload is verifiable but not encrypted (by default).	Encrypted (Local) or Signed (Public) by design.	Opaque, server determines validity/state.
Algorithm Agility	Allows various algorithms (HS256, RS256, etc.) which can be a source of vulnerabilities if not handled correctly.	Fixed algorithms, no agility (prevents algorithm confusion attacks).	N/A (token is an identifier, not a crypto object).
Default Security	Requires careful implementation to avoid pitfalls.	Stronger defaults, harder to misuse.	Relies on server-side session management.
Key Management	Symmetric (HS) or Asymmetric (RS) keys.	Symmetric (Local) or Asymmetric (Public) keys, explicitly defined.	Server-side lookup.
Use Case	General-purpose auth, APIs, SSO.	High-security APIs, microservices, strong guarantees.	Traditional web apps (server-rendered).

HS256/384/512 vs RS256 vs ES256

Feature	HS256/384/512	RS256	ES256
Family	HMAC (symmetric)	RSA PKCS#1 v1.5 (asymmetric)	ECDSA P-256 (asymmetric)
Key	One shared secret	Private key signs; public key verifies	EC private key signs; public key verifies
Key exchange	Must be shared securely	Public key is safe to distribute	Public key is safe to distribute
Signature size	Hash size (32/48/64 bytes)	Key size (typically 256 bytes for 2048-bit RSA)	64 bytes
Best for	Single-service APIs, same trust domain	Multi-service verification without sharing secrets	Compact signatures, high-traffic / constrained clients
Cost	Cheapest	Moderate (RSA verify is cheap, sign slower)	Very fast both ways

Production Best Practices & Security

Use HS256/384/512, RS256/384/512, PS256/384/512, or ES256/384/512 deliberately — don't let the token header pick the algorithm for you. Why:an attacker who can influence alg can steer verification into a weaker path (see the algorithm-confusion attack below).

Never use the public key as an HMAC secret — if an RS256 token can be accepted as HS256, anyone can forge it using the public key. Why:that is the classic RS256→HS256 algorithm-confusion attack.

Always verify signatures — a decoded token without verification is just untrusted data. Why:without it, an attacker can mint their own tokens with any claims they want.

Validate iss, aud, and exp on the server — never trust a token the client decoded. Why:replay and cross-app token reuse are only prevented by server-side validation.

Keep secrets server-side — the secret used for HS* signing must never live in client-side code. Why:whoever holds the secret can forge tokens.

Fetch JWKS dynamically and match kid — issuers rotate keys; hardcoding a key breaks on rotation and accepting any key lets an attacker swap in their own. Why:rotation is routine, and kid matching ensures you use the current, correct key.

Don't paste production private keys into web tools — this one runs 100% locally, but general caution still applies. Why:a compromised private key lets an attacker sign valid-looking tokens for your whole system.

Frequently Asked Questions

HS256 uses a single shared secret for both signing and verification. Anyone with the secret can create or verify tokens.

RS256 uses asymmetric key pairs: a private key signs tokens, and anyone with the public key can verify them.

Use HS256 for simple architectures where the signer and verifier are the same system. Use RS256 when multiple services need to verify tokens without sharing a secret — think microservices or third-party integrations.

RS256 is more secure but requires key management infrastructure.

The algorithm confusion attack (also called the RS256 → HS256 swap) exploits libraries that pick the verification algorithm from the token header instead of a fixed allowlist.

Here is how it works: an attacker takes a valid RS256 token (verified with a public key) and rewrites the header's alg to HS256. They then re-sign the token with HMAC-SHA256 using the RSA public key itself as the HMAC secret. If your server — told to use HS256 — verifies with the RSA public key as the shared secret, the forged token passes signature checks, and the attacker can then put any claims they want in the payload (for example, role: admin).

Defenses:

Allowlist algorithms — never accept alg from the header; pin it to a fixed list (e.g. algorithms: ['RS256'] in jsonwebtoken/PyJWT, or Validation::new(Algorithm::RS256) in Rust).
Never use a public key as an HMAC secret — the public key is, by definition, public, so anyone can forge an HMAC signature with it.
Reject none and mixed-type keys — also disable the alg: none path, which lets attackers omit the signature entirely.

This tool supports both families so you can reproduce the attack: encode the same claims as HS256 using the RSA public key as the secret, then watch the checklist flag the token as valid when the verifier accepts HS256.

This tool supports the major JWT signing algorithm families — HMAC (HS256/384/512), RSA PKCS#1 v1.5 (RS256/384/512), RSA-PSS (PS256/384/512), and ECDSA (ES256/384/512) — plus alg: none for testing signature-stripping attacks:

HS256 / HS384 / HS512 — HMAC with SHA-256, SHA-384, or SHA-512. One shared secret both signs and verifies. Fast and simple, but the secret must be shared securely with every verifier. Ideal when signer and verifier are the same system or a small, trusted group.
RS256 / RS384 / RS512 — RSA PKCS#1 v1.5 with SHA-256, SHA-384, or SHA-512. A private key signs; anyone with the public key verifies. RS256 is the default for most OIDC providers (Google, Auth0, Keycloak). Use it when many services must verify tokens without sharing a secret.
PS256 / PS384 / PS512 — RSA-PSS, the randomized RSA variant. Same trust model as RS*, with signatures salted per message for stronger security properties.
ES256 / ES384 / ES512 — ECDSA over P-256, P-384, or P-521. Same asymmetric trust model as RS*, but with compact signatures (64/96/132 bytes) and very fast verification. Great for high-traffic APIs and constrained clients.

Choosing: single service → HS256; multi-service / third-party verification → RS256 or ES256; minimal bandwidth or CPU → ES256. The security of an HMAC depends on the secret's entropy, not the hash size — HS384 and HS512 are not inherently stronger than HS256.

All three are HMAC signatures — the only difference is the underlying hash function: SHA-256, SHA-384, or SHA-512.

HS256 is the default for most APIs and libraries. SHA-256 output is 256 bits, which is well beyond current brute-force capability, so HS384 and HS512 are not inherently 'more secure' — the security of an HMAC depends on the secret's entropy, not the hash size.

Choose whatever your server and client libraries support consistently. The critical rule is that the verifier must use the same algorithm that signed the token — the alg header must match, or verification fails.

There's no protocol-level limit, but practical constraints apply. Most authentication systems keep JWTs under 4 KB to fit within HTTP cookie size limits.

Large payloads increase network overhead on every API request — a 10 KB JWT adds 10 KB to every authenticated call.

Best practice: store minimal claims (sub, iss, exp) in the JWT and fetch detailed user data from your API. If your JWT exceeds 8 KB, consider using an opaque token or storing claims server-side.

Paste your JWT string (the three dot-separated Base64URL segments) into the input field. The tool automatically decodes the header (algorithm, token type) and payload (claims like sub, exp, iss) into readable JSON.

In Decode / Verify mode, enter the shared secret to check an HS* signature, or paste a JWK / PEM public key or a JWKS URL to verify RS*, PS*, and ES* tokens — the tool computes the signature locally and compares it against the provided one.

Paste the token in Decode / Verify, then enter the issuer's JWKS URL (for example, https://accounts.google.com/.well-known/jwks.json or Auth0's https://{tenant}.auth0.com/.well-known/jwks.json). The tool fetches the key set, reads the kid from your token's header, and picks the matching key to verify the signature locally with Web Crypto.

If the endpoint does not allow cross-origin (CORS) requests, the fetch will fail — in that case paste the full JWKS document, its keys array, or just the single JWK matching your kid into the JWK field instead. This tool only ever reads the public key set; no token material is sent anywhere.

In Decode / Verify, once the payload is parsed the tool updates once per second:

exp — a live countdown (e.g. Expires in 1h 14m 05s) plus a progress bar showing how much of the token's lifetime has elapsed (measured from iat or nbf to exp). The bar shifts green → amber → red as it approaches expiry.
nbf — a countdown until the token becomes valid if it is in the future, otherwise it reports how long it has been valid.

The countdown is computed from the current time on your device, so it is an approximation for inspection — your server's clock is the source of truth for actual validation.

exp is a Unix timestamp (seconds since January 1, 1970) telling you when the token stops being valid. Decode your token and look for exp in the payload.

To judge how much time is left, convert it with new Date(exp * 1000) in the browser console, or subtract the current Unix time. iat (issued at) tells you when the token was created, and nbf (not before) says when it becomes valid — a token with nbf in the future is not yet usable.

Production rule of thumb: access tokens expire in 5–15 minutes; refresh tokens in days to months.

The checklist inspects the decoded payload and reports, per claim, whether it is present and what state it is in:

exp — present, and expired or expiring in X
nbf — present, and not-yet-valid or active
iss — present, and whether it matches the expected issuer you entered
aud — present, and whether it includes the expected audience you entered
iat — present, and how long ago the token was issued

A missing check just means the claim is absent from the payload — which is itself useful to know, since most production verifiers require exp, iss, and aud.

No — and this tool tells you exactly that before you paste one. All signing happens locally in your browser via the Web Crypto API, and nothing is transmitted to any server, so this page is no less safe than running OpenSSL on your own machine.

But the general rule stands: private keys should never be pasted into online tools. A compromised private key lets an attacker sign valid-looking tokens for your whole system, and you cannot verify what a third-party page does with it. For real key material, use a local CLI (openssl dgst -sha256 -sign, or your language's JWT library). Use throwaway keys with this tool for testing and reproduction only.

Yes. Encoding, decoding, and signature verification happen entirely in your browser using the Web Crypto API. Your tokens, secrets, and keys never leave your device.

The only network request is the JWKS URL you optionally provide, which is fetched directly from your browser to that issuer over HTTPS so the public keys can be read — no token data is included in that request, and nothing is stored or logged by this site.

Both tools decode JWTs entirely in your browser — BetterPass just pairs that with a few extras.

A whole token toolkit — PASETO, Opaque, SAML, and OIDC tools plus a built-in JWT-vs-PASETO comparison, so you can evaluate and debug every token format in one place.
Educational depth — production best practices, glossary-level FAQs, and plain-language explainers on claims and algorithms.
No account, no tracking — tokens and secrets never leave your device, and nothing is stored or logged.
Free and open-ended — no sign-up, no usage limits.

For niche algorithms or ASN.1 parsing, dedicated services may go further — but for everyday JWT encode/decode/verify and learning, this tool covers the workflow locally.