Question 1

What does this JWT debugger check for security-wise?

Accepted Answer

The algorithm in the header (flagging alg:none as critical), expiry and issued-at times (flagging tokens longer than 24 hours as high-risk), sensitive claim names like 'password', 'secret', 'ssn', or 'credit_card', whether the token is expired, and — when you provide a secret or public key — whether the signature actually verifies. Most JWT debuggers just decode and show; this one tells you what's wrong.

Question 2

Is it safe to paste my JWT here?

Accepted Answer

Yes. The debugger runs entirely in your browser — the token never leaves your machine, never hits our server, never reaches analytics. You can verify this by opening DevTools Network tab and pasting a token: zero outbound requests. That said, any JWT you paste into any web tool (including ours) should be one you control, not a production customer token.

Question 3

What is alg:none and why is it dangerous?

Accepted Answer

alg:none is a JWT header value that tells the verifier to skip signature verification entirely. It was originally included for debugging but became a critical vulnerability: attackers change a signed JWT's algorithm to 'none' and strip the signature, and vulnerable libraries accept the unsigned token as valid. Any JWT library that accepts alg:none in production is a security bug — we flag it as critical.

Question 4

Why do you flag tokens longer than 24 hours?

Accepted Answer

Access tokens should be short-lived (15-60 minutes) because they can't be revoked once issued — they're valid until they expire. A stolen 30-day access token gives an attacker 30 days of access. For longer sessions, use a short-lived access token plus a refresh token that CAN be revoked from the server. Long-lived access tokens are a security anti-pattern, not just a best-practice miss.

Question 5

What's the difference between HS256 and RS256?

Accepted Answer

HS256 uses a shared secret — both the issuer and verifier need the same key, which means any service that verifies tokens can also forge them. RS256 uses a key pair — only the issuer has the private key, verifiers only need the public key and can't forge tokens. For microservices or multi-tenant systems, RS256 is almost always the right choice. If you see HS256 with a service architecture where verifiers shouldn't be able to forge, that's a finding worth flagging.

Question 6

The signature verification failed but the token looks right — why?

Accepted Answer

Common causes: wrong secret/key (most common — verify you're using the exact secret), algorithm mismatch (the token's alg doesn't match the key type — can't verify an HS256 token with an RSA public key), trailing whitespace in the pasted secret, or the token was signed with a different key than you're checking. Algorithm confusion attacks exploit exactly this mismatch — libraries that auto-select the algorithm from the header are vulnerable.

JWT Debugger with Security Warnings

Frequently Asked Questions

What does this JWT debugger check for security-wise?

Is it safe to paste my JWT here?

What is `alg:none` and why is it dangerous?

Why do you flag tokens longer than 24 hours?

What's the difference between HS256 and RS256?

More Free Tools