JWT Decoder

How to use this tool

1. Paste your JWT. Copy a JWT from your application (e.g., from a browser cookie, localStorage, or API response) and paste it into the text area.
2. Review the decoded sections. The tool instantly displays the header (algorithm, token type) and payload (claims) as formatted JSON.
3. Check the validity and expiry. The time-window badge checks `exp` and `nbf` separately from signature verification; inspect the algorithm warning before treating the decoded claims as trustworthy.
4. Inspect standard claims. The standard claims table translates Unix timestamps for `iat`, `exp`, and `nbf` into human-readable dates.
5. Copy any section. Use the copy buttons next to each section to copy the formatted JSON or the raw base64url part.
6. Optionally check a signature. Open the signature check and paste a test HMAC secret or public key. The check runs locally and does not replace server-side validation.

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.

Optional signature verification

Verifying a JWT signature requires the secret or public key used when the token was signed. This decoder can check HS256/384/512 with a secret you paste, or RS, PS, and ES signatures with a public PEM or JWK key. The check runs in this browser and keeps the signature result separate from the exp/nbf time window.

HMAC keys are shared secrets, so use a test key and do not paste a production secret into any web page. Public keys are intended to be shared, but this local check still does not validate issuer policy, audience, or whether your application should accept the token. Always enforce those rules and the expected algorithm on the server.

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.