A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined by RFC 7519. JWTs allow claims — pieces of information about a user or session — to be securely transmitted between parties as a JSON object. They are self-contained, meaning the token itself carries all the data needed to authenticate a request without querying a database or session store. This makes JWTs popular for stateless authentication in modern web applications and APIs.
Every JWT consists of three parts separated by dots: header.payload.signature. Each part is Base64URL-encoded. The header typically contains the signing algorithm (alg) and token type (typ). The payload holds the claims — the actual data being transmitted. The signature is created by signing the encoded header and payload with a secret key (HMAC) or a private key (RSA/ECDSA), ensuring the token has not been tampered with.
| Field | Description | Example |
|---|---|---|
alg | Signing algorithm | HS256, RS256, ES256 |
typ | Token type | JWT |
kid | Key ID (for key rotation) | my-key-1 |
| Claim | Full Name | Purpose |
|---|---|---|
sub | Subject | Identifies the user or entity the token represents |
iat | Issued At | Unix timestamp when the token was created |
exp | Expiration | Unix timestamp after which the token is invalid |
iss | Issuer | Identifies who issued the token (e.g., your auth server) |
aud | Audience | Identifies the intended recipient (e.g., your API) |
nbf | Not Before | Unix timestamp before which the token is not valid |
jti | JWT ID | Unique identifier to prevent token replay |
JWTs are widely used across the modern development stack. In API authentication, clients send a JWT in the Authorization: Bearer header with each request. OAuth 2.0 and OpenID Connect use JWTs as access tokens and ID tokens. Single Sign-On (SSO) systems issue JWTs so users can authenticate once and access multiple services. JWTs also appear in session management, webhook signatures, and service-to-service communication in microservice architectures.
JWTs are encoded, not encrypted. Anyone who has a JWT can decode the header and payload — no secret key is needed to read the contents. This means you should never put sensitive information (passwords, credit card numbers, personal secrets) in a JWT payload unless you also apply JWE (JSON Web Encryption). This decoder tool demonstrates exactly that: it reads the header and payload without any key at all.
This tool decodes but does not verify signatures. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for asymmetric algorithms like RS256 or ES256). In production systems, always verify the signature before trusting any claims in the payload.
Paste any JWT into the text area above. The decoder will instantly split the token into its three parts and display the header and payload as formatted, syntax-highlighted JSON. Time-based claims like exp, iat, and nbf are automatically converted to human-readable dates, and the status bar shows whether the token is expired. The raw signature is displayed separately for reference.
This decoder runs 100% client-side in your browser. Your tokens are never transmitted to any server — they stay entirely on your machine. This makes it safe to decode production tokens during debugging without risking exposure.