JWT Split Parts Viewer
How it works
A JWT (JSON Web Token) consists of three Base64url-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm; the payload carries claims (user ID, roles, expiry, etc.); the signature verifies that the header and payload have not been tampered with. This tool splits a JWT and decodes the header and payload for inspection.
**JWT structure details** Header: {"alg": "HS256", "typ": "JWT"} — or RS256 for RSA, ES256 for ECDSA. Payload (registered claims): iss (issuer), sub (subject/user ID), aud (audience), exp (expiry Unix timestamp), nbf (not before), iat (issued at), jti (JWT ID for replay prevention). Signature: HMAC-SHA-256(base64url(header) + "." + base64url(payload), secret) for HS256.
**Security considerations** JWTs are signed, not encrypted — the payload is readable by anyone with the token. Never include sensitive data (password, SSN, credit card) in a JWT payload. Always verify the signature server-side before trusting claims. The "alg: none" attack: if your JWT library accepts the algorithm from the token header, an attacker can set alg=none and remove the signature, gaining access with a forged payload — always specify the expected algorithm explicitly.
**exp claim and clock skew** Always validate the exp claim server-side. A 5-minute clock-skew tolerance is conventional for distributed systems where server clocks may differ slightly. Never extend token lifetime by modifying the exp claim client-side — the signature would be invalid.
Frequently Asked Questions
- Registered claims (all optional but recommended): iss (issuer — who created the token), sub (subject — the entity the token is about, usually user ID), aud (audience — intended recipients), exp (expiration time — Unix timestamp, reject after this time), nbf (not before — Unix timestamp, reject before this time), iat (issued at — when the token was created), jti (JWT ID — unique identifier for the token, used for replay prevention by blacklisting used JTIs).
- If a JWT library reads the algorithm from the token header and accepts 'none' as a valid algorithm, an attacker can forge a token: set alg=none, craft any payload (e.g., sub=admin, role=superuser), remove the signature, and submit header.payload. (with an empty signature part). A vulnerable library skips signature verification for alg=none and accepts the forged token. Fix: always specify the expected algorithm explicitly on the server side and reject any token with a different algorithm — never read alg from the untrusted token header alone.
- No. The JWT payload is Base64url encoded, not encrypted — it is trivially readable by anyone who intercepts or inspects the token. Never include: passwords, credit card numbers, SSNs, medical data, or any sensitive information. JWTs should contain only the minimum claims needed for authorization decisions: user ID, roles/permissions, expiration, and audience. If you need to transmit sensitive data in a JWT, use JWE (JSON Web Encryption) which encrypts the payload. Standard JWTs (JWS) are signed but not encrypted.
- Parse the payload (middle section, base64url decode → JSON) and read the exp claim. It is a Unix timestamp in seconds. In JavaScript: const payload = JSON.parse(atob(token.split('.')[1])); const isExpired = Date.now() / 1000 > payload.exp. However, this does NOT verify authenticity — you are reading an unverified payload. An attacker can modify the exp claim to extend validity. Always verify the signature before trusting any claim. This is useful for UI display (showing 'session expires in X minutes') but not for authorization decisions.