What is JWT?
JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It is compact, self-contained, and widely used for authentication and information exchange. JWT uses Base64url encoding with digital signatures (or encryption) to ensure data integrity and trusted origin verification.
JWT Structure
A standard JWT consists of three parts separated by dots (.):
Header.Payload.Signature
Header
The header typically contains two parts: the token type (typ, usually JWT) and the signing algorithm (alg, such as HS256, RS256, ES256). Optional fields include kid (Key ID), cty (Content Type), and others.
Payload
The payload contains claims — statements about an entity (typically the user) and additional data. Claims are categorized into three types:
- Registered Claims: Predefined but optional claims, including
iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID).
- Public Claims: Claims registered in the IANA JWT Claims Registry or using collision-resistant namespaces.
- Private Claims: Custom claims created by the parties involved for sharing specific information.
Signature
The signature is used to verify that the message has not been tampered with during transmission. It is calculated by signing the Base64url-encoded Header and Payload with a secret key using the algorithm specified in the Header: HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret)
How JWT Works
The typical JWT workflow:
- User Login: The client sends login credentials to the server.
- Token Issuance: After verifying credentials, the server generates a JWT containing user information, signs it with a server-side secret, and returns it to the client.
- Token Storage & Usage: The client stores the JWT locally (localStorage, sessionStorage, or Cookie) and includes it in subsequent requests via the
Authorization: Bearer <token> header.
- Token Verification: The server validates the JWT signature and expiration on each request before processing.
- Token Expiry: The client may refresh the token before expiration, or the user must re-authenticate to obtain a new token.
JWT Claims Reference
| Claim | Full Name | Description |
|---|
iss | Issuer | The principal that issued the JWT |
sub | Subject | The principal that is the subject of the JWT (typically a user ID) |
aud | Audience | The intended recipients of the JWT |
exp | Expiration Time | The expiration time after which the JWT must not be accepted (Unix timestamp) |
nbf | Not Before | The time before which the JWT must not be accepted (Unix timestamp) |
iat | Issued At | The time at which the JWT was issued (Unix timestamp) |
jti | JWT ID | A unique identifier for the JWT, used to prevent replay attacks |
alg | Algorithm | The signing/encryption algorithm (in the Header) |
typ | Type | The type of the token (in the Header, typically JWT) |
Common Signing Algorithms
| Algorithm | Type | Description |
|---|
HS256 | HMAC with SHA-256 | Symmetric signing — same key used to sign and verify |
HS384 | HMAC with SHA-384 | Stronger variant of HS256 |
HS512 | HMAC with SHA-512 | Strongest HMAC variant |
RS256 | RSA with SHA-256 | Asymmetric signing — private key signs, public key verifies |
RS384 / RS512 | RSA variants | Stronger RSA signing |
ES256 | ECDSA with P-256 and SHA-256 | Elliptic curve asymmetric signing — shorter and faster than RSA |
ES384 / ES512 | ECDSA variants | Stronger ECDSA signing |
PS256 | RSA-PSS with SHA-256 | RSA with Probabilistic Signature Scheme padding |
none | No signature | Insecure unsigned mode — never use in production |
Common Use Cases
- API Authentication: In RESTful APIs, the client includes a JWT in the Authorization header of every request, eliminating server-side session state.
- Single Sign-On (SSO): A user logs in to system A and obtains a JWT that can be used to access systems B and C — each system independently validates the same token.
- Microservice Communication: JWTs carried between services allow downstream services to independently verify request origin and permissions without contacting an authentication center.
- Information Exchange: Securely transmitting structured claim information between multiple parties (e.g., id_token in OAuth 2.0).
- Mobile Applications: Native apps cannot use Session/Cookie-based authentication; JWT's lightweight, stateless nature is an ideal fit.
JWT Best Practices
- Avoid storing sensitive data in Payload: The Payload is only Base64url-encoded, not encrypted — anyone can decode and read it. Never put passwords, credit card numbers, or other sensitive data in a JWT.
- Set reasonable expiration times: The
exp claim is critical. Access tokens are typically set to 15 minutes to several hours, while refresh tokens can last days.
- Always use HTTPS: JWTs transmitted over the network must always travel over HTTPS to prevent man-in-the-middle interception.
- Verify signatures server-side: Always validate JWT signatures on the server. Client-side parsing tools (like this one) are for debugging and inspection only and cannot perform cryptographic verification in the browser.
- Reject 'none' algorithm: In production, you must disable or reject JWTs with alg: none, as they allow attackers to forge arbitrary tokens.
Why Choose Our JWT Parser?
- Real-Time Auto-Parse: Paste a JWT and see results instantly — no buttons needed, what you type is what you see.
- Full-Field Annotations: Every JWT field is displayed with its full name and bilingual (English/Chinese) labels for clarity.
- Human-Friendly Timestamps: exp, iat, nbf and other timestamps are automatically converted to readable dates with relative times (e.g., "-3h", "Expired").
- Side-by-Side View: Header and Payload are displayed in a split-panel layout with detailed field breakdowns at a glance.
- Signature Status Visualization: Clearly shows whether the token includes a signature and provides security guidance about client-side verification limitations.
- One-Click Copy: Separate copy buttons for Header and Payload make debugging effortless.
- Free & Offline: All parsing happens locally in your browser — no registration, no server dependency, and your data never leaves your device.