JWT Decoder

Algorithm comparison

Common JWT vulnerabilities

• Algorithm confusion (alg:none): A critical vulnerability in some old JWT libraries where setting "alg":"none" in the header caused the library to skip signature verification entirely. Always enforce the expected algorithm server-side and reject tokens with alg:none or an unexpected algorithm.
• Algorithm substitution (RS256 -> HS256): If a server expects RS256 but a library also accepts HS256, an attacker can create a token signed with HS256 using the server's public key as the HMAC secret. Mitigate by explicitly specifying the expected algorithm when verifying.
• Key confusion with JWKS: Accepting JWTs with a jku (JWK Set URL) or x5u header pointing to an attacker-controlled URL. Always verify keys from a trusted, hard-coded endpoint only.
• Weak secrets: HMAC JWTs signed with short or dictionary-guessable secrets are vulnerable to offline brute-force. Use a cryptographically random secret of at least 256 bits (32 bytes).

What is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It consists of three base64url-encoded sections joined by dots:

• Header: identifies the signing algorithm (e.g., HS256, RS256) and the token type (JWT).
• Payload: contains the claims: statements about an entity (typically the authenticated user) and additional metadata.
• Signature: a cryptographic signature over the header and payload, used by the server to verify the token has not been tampered with.

Because the header and payload are only base64url-encoded (not encrypted), anyone who holds the token can read its contents. This tool does exactly that: it decodes the readable sections without needing the signing key.

Understanding standard JWT claims

RFC 7519 defines a set of reserved claim names that have specific meanings:

• iss (Issuer): the principal that issued the token, e.g., https://accounts.google.com.
• sub (Subject): the principal that is the subject of the JWT, typically a user ID.
• aud (Audience): the recipients the JWT is intended for.
• exp (Expiration Time): the time after which the JWT must not be accepted. Unix timestamp in seconds.
• nbf (Not Before): the time before which the JWT must not be accepted. Unix timestamp in seconds.
• iat (Issued At): the time the JWT was issued. Useful for determining token age.
• jti (JWT ID): a unique identifier that can be used to prevent the JWT from being replayed.

Applications may also include custom (private) claims alongside these standard ones. Custom claims are displayed in the payload section but are not interpreted by this tool.

Why signature verification is out of scope

Verifying a JWT signature requires the secret or public key used when the token was signed. For HMAC algorithms (HS256, HS384, HS512), that is a shared secret that must never be exposed to a browser. For RSA and EC algorithms ( RS256, ES256, etc.), the public key is technically shareable, but you would need to know where to fetch it, typically from the issuer's JWKS endpoint.

A future version of this tool may add optional public-key verification for RS256/ES256 tokens when you supply the public key yourself.

Security considerations when using JWTs

• Never store JWTs in localStorage for sensitive applications. Cross-site scripting (XSS) attacks can read localStorage. HttpOnly cookies are safer.
• Always validate the signature server-side. Decoding tells you what is in the token; only signature verification tells you whether to trust it.
• Check the exp claim. An expired token must not be accepted, even if the signature is valid.
• Restrict the aud claim. Validate that the token was intended for your service to prevent token reuse across services.
• Avoid the alg: none attack. Some old libraries accepted tokens with "alg":"none", skipping signature verification entirely. Always specify the expected algorithm explicitly.