JWT Decoder - Decode JSON Web Tokens

Understanding JSON Web Tokens

A JSON Web Token (JWT) is a compact, URL-safe format defined in RFC 7519 for representing claims - assertions about a subject - transferred between two parties. A JWT is three Base64URL-encoded segments joined by dots: header.payload.signature. It is pronounced "jot", and it is built on two companion specs: JSON Web Signature (RFC 7515) supplies the signing, and JSON Web Algorithms (RFC 7518) enumerates the permitted algorithms.

Its appeal is statelessness. When you sign in, the server issues a signed token that your client stores and attaches to each subsequent request as Authorization: Bearer <token>. Because the signature proves the token was minted by a holder of the key, the server can trust the claims inside without a session lookup - which is why JWTs became the default for OAuth 2.0 access tokens, OpenID Connect ID tokens, and service-to-service auth in microservice and Kubernetes environments.

The three parts of a JWT

• Header - contains the token type (typ: "JWT") and signing algorithm (alg: "HS256", "RS256", etc.)
• Payload - contains claims: data about the user (sub, email, role) and metadata (iat, exp)
• Signature - a cryptographic signature of the header + payload, verifiable only with the signing key

Important: JWTs are encoded, not encrypted

A common misconception: JWTs are not encrypted. The header and payload are only Base64URL-encoded, which anyone can decode without a key - as this tool demonstrates. Never put sensitive data like passwords or payment details in a JWT payload unless you use JWE (JSON Web Encryption). The signature ensures the token was not modified, but the contents are readable by anyone who has the token.

Signing algorithms and the alg:none attack

The alg field in the header names the algorithm. HS256is HMAC with SHA-256 - a symmetric scheme where the same shared secret both signs and verifies, fine when one service does both. RS256 and ES256 are asymmetric (RSA and ECDSA respectively): a private key signs, and anyone with the public key can verify without being able to forge, which is what makes them the right choice for identity providers publishing a JWKS endpoint at /.well-known/jwks.json.

Two classic vulnerabilities come from trusting that header. The alg:none attack sets the algorithm to none and sends an empty signature; a library that honours the header accepts anything. The RS256-to-HS256 confusion attack takes the server's public RSA key - which is public by definition - and uses it as an HMAC secret. The defence for both is the same: pin the expected algorithm server-side rather than reading it from the token you are validating.

When debugging, the claims worth checking first are exp and iat, both Unix timestamps in seconds, not milliseconds - feeding a JavaScript Date.now() value straight into exp produces a token valid until the year 54,000, a very common bug. nbf makes a token invalid before a given time and is a frequent cause of "works on my machine" failures when server clocks drift. And because JWTs are self-contained, they cannot be revoked by deleting a database row - the standard mitigations are short lifetimes (5–15 minutes) plus a refresh token, or a server-side denylist keyed on jti.

Decoding here is arithmetic, not cryptography: split on dots, Base64URL-decode, parse JSON. It happens entirely in this browser tab and no token is ever transmitted or stored - though as a habit, prefer development tokens over production ones in any online decoder.