JWT Security Checker
Paste a JWT to decode the header and payload, check for algorithm none attack, expired tokens, and missing iss/aud claims without transmitting the token to any server.
Calculations run locally in your browserJWT Security Checker
The JWT Security Checker decodes JWT headers and payloads, checks for algorithm none and RS256-to-HS256 attacks, validates exp/iss/aud claims, and flags sensitive data in payload.
• Debug a JWT to inspect claims during API integration development
• Check for the algorithm none vulnerability in a JWT implementation
• Verify that exp, iss, and aud claims are present before shipping an auth flow
• Inspect a JWT from a log or error report to diagnose authentication failures
How JWT Security Checker fits into production review
JWT Security Checker belongs at the boundary between authentication evidence and authorization decisions. The useful review starts with the header: algorithm, kid, typ, and any unexpected fields that might influence library behavior. Then inspect the payload claims that decide trust, especially iss, aud, sub, exp, nbf, iat, scope, roles, tenant identifiers, and custom authorization flags. A decoded token is evidence, not a login session.
The high-risk failures are concrete. alg:none should be rejected before any payload value is considered. RS256-to-HS256 confusion matters when a verifier accidentally treats a public key as an HMAC secret. kid values need scrutiny because some systems use them to select keys from a JWKS cache, filesystem path, or remote source. Expired tokens, missing audience checks, and issuer mismatches are common enough that they should be written into the review record instead of discussed only in chat.
A production operator should also look for payload hygiene. JWT payloads are base64url encoded, not encrypted, so email addresses, internal ids, feature flags, roles, and debugging claims can leak through browser storage, logs, referrers, crash reports, and screenshots. The correct review output states which claims are security-critical, which are merely descriptive, and whether the relying service verifies the signature and claims server-side before accepting the token.
When this result can be misleading
Decoding a JWT does not verify it. A parser can display neat JSON from a forged token, an expired token, or a token issued for a different audience. The result should never be treated as proof of identity unless the verification key, issuer, audience, allowed algorithms, and clock policy are all known. For opaque provider tokens, the right answer may be introspection rather than local JWT handling.
Key discovery adds subtle failure modes. JWKS caches can be stale during rotation, kid collisions can select the wrong key, and libraries may accept algorithms that the issuer never intended to support. A token that passes in one environment may fail in another because staging and production use different issuer URLs, key sets, or accepted audiences. Record the environment and JWKS source with the finding.
Claim presence also needs context. A token may include roles that the service ignores, scopes that only apply to a different resource server, or a tenant field that is never compared to the requested object. Conversely, a minimal token can be safe when the application obtains authorization from a separate policy system. Treat the token as one input to an authorization chain, not as the entire chain.