The Ultimate Guide to JSON Web Tokens (JWT)
JSON Web Tokens (JWT) are an open, industry-standard (RFC 7519) method for representing claims securely between two parties. They are overwhelmingly used in modern web development for Single Sign-On (SSO), REST API authentication, and securely passing user session data.
Despite their complex appearance, a JWT is just a Base64Url encoded string consisting of three distinct parts separated by dots (.).
1. The Header (Red)
The header typically consists of two parts: the type of the token (which is JWT), and the cryptographic signing algorithm being used, such as HMAC SHA256 (HS256) or RSA (RS256).
2. The Payload & Standard Claims (Purple)
The payload contains the "claims." Claims are statements about an entity (typically, the user) and additional data. While developers can add custom data, there are several Registered Claims that provide standard interoperability:
iss(Issuer): Identifies the principal that issued the JWT.sub(Subject): Identifies the principal that is the subject of the JWT (often a User ID).aud(Audience): Identifies the recipients that the JWT is intended for.jti(JWT ID): Provides a unique identifier for the JWT to prevent replay attacks.
3. The Signature & Cryptographic Verification (Blue)
To create the signature part, the server takes the encoded header, the encoded payload, a secret key, and the algorithm specified in the header, and hashes them together.
The signature is the magic that makes JWTs secure. It is used to verify the message wasn't changed along the way. If a hacker intercepts your token and changes "admin": false to "admin": true, the resulting signature will not match what the server expects, and the request will be instantly denied.
How to test this: If your token uses the HS256algorithm, our tool above will reveal a "Verify HS256 Signature" input. Paste your backend secret key into this box. Our tool uses the browser's native Web Crypto API to mathematically verify the signature against the payload, entirely on your local machine.
Understanding JWT Timestamps (`exp`, `iat`, `nbf`)
Handling expiration is a massive pain point for developers. JWTs use Unix Epoch time (the number of seconds since Jan 1, 1970). Our decoder automatically intercepts these fields and translates them into human-readable local times:
exp(Expiration Time): The exact moment the token becomes invalid. Our tool shows a red "Token Expired" badge if this time is in the past.iat(Issued At): The exact moment the token was created and handed to the client.nbf(Not Before): A time before which the token must NOT be accepted for processing.