JWT Decoder
Decode JSON Web Tokens and inspect claims — all in your browser, nothing sent to any server
Paste a JWT above to instantly decode its header, payload, and signature. All decoding happens in your browser — your token never leaves this page.
What Is a JWT?
A JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between two parties as a compact, URL-safe string. JWTs are widely used for authentication and authorization in modern web applications — when you log into a service, the server typically issues a JWT that your client sends with every subsequent request to prove your identity.
A JWT consists of exactly three Base64URL-encoded parts, separated by dots (.):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← Header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ ← Payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← Signature
The Three Parts of a JWT
Header
The header is a JSON object that describes the token’s type and the signing algorithm used. It always contains at minimum the alg (algorithm) field and usually the typ (type) field:
{
"alg": "HS256",
"typ": "JWT"
}
Common algorithms include HS256 (HMAC-SHA256), RS256 (RSA-SHA256), and ES256 (ECDSA-P256-SHA256). The algorithm determines how the signature is created and verified.
Payload
The payload is a JSON object containing claims — statements about the subject of the token and any additional metadata. Claims are categorized as:
- Registered claims — standard fields defined in RFC 7519 (described below)
- Public claims — custom fields that should be defined in the IANA JWT Claims Registry to avoid collisions
- Private claims — custom fields agreed upon between producer and consumer
Signature
The signature verifies that the token has not been tampered with. For HMAC-based algorithms (HS256/HS384/HS512), the signature is computed as:
HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)
For RSA and ECDSA algorithms, a private key is used to sign and a public key is used to verify.
Standard JWT Claims (Registered Claims)
RFC 7519 defines seven standard registered claim names. This tool automatically detects and annotates them:
| Claim | Full Name | Description |
|---|---|---|
iss | Issuer | Identifies who issued the token (e.g., "https://auth.example.com") |
sub | Subject | Identifies the principal the token is about (e.g., a user ID) |
aud | Audience | Identifies the recipients the token is intended for |
exp | Expiration Time | Unix timestamp after which the token must be rejected |
nbf | Not Before | Unix timestamp before which the token must not be accepted |
iat | Issued At | Unix timestamp recording when the token was issued |
jti | JWT ID | Unique identifier for the token, used to prevent replay attacks |
Decoding vs. Verifying a JWT
There is an important distinction between decoding and verifying a JWT:
Decoding simply Base64URL-decodes the header and payload to read their JSON contents. No secret is required. Anyone can decode a JWT — the payload is not encrypted, only encoded. This tool decodes instantly as you paste your token.
Verifying checks that the signature was created by the expected secret or private key, confirming the token’s authenticity and integrity. Without verification, you cannot trust the claims in the payload. This tool supports HMAC signature verification (HS256, HS384, HS512) using a secret you provide.
JWT Expiry and Timing Claims
The exp claim is the most important security claim. Servers must reject tokens whose exp timestamp is in the past. This tool automatically:
- Detects the
expclaim and shows whether the token is currently valid or expired - Displays how long until expiry (or how long ago it expired)
- Converts all Unix timestamps (
exp,iat,nbf) to human-readable UTC dates
When working with JWTs, always validate expiry on the server side. Never trust client-side expiry checks alone.
Common JWT Use Cases
Authentication: After login, a server issues a JWT. The client stores it (typically in memory or a secure cookie) and sends it as a Bearer token in the Authorization header. The server validates the JWT on each request without querying a database.
Authorization: JWTs can contain role or permission claims ("role": "admin") that let servers make authorization decisions without a database lookup.
Information exchange: JWTs can securely transmit signed data between services in a microservices architecture.
OAuth 2.0 / OpenID Connect: JWTs are the standard format for ID tokens and access tokens in modern identity protocols.
Privacy and Security
This JWT decoder runs entirely in your browser. Your token is processed by local JavaScript — it is never sent to any server, logged, or stored. You can safely use this tool in an air-gapped environment.
As a best practice, avoid pasting long-lived production tokens into any online tool. Use short-lived tokens or tokens from non-production environments for debugging.
Frequently Asked Questions
Can I read the JWT payload without the secret? Yes. The payload is Base64URL-encoded, not encrypted. Anyone can decode and read it. This is why you should never put sensitive secrets inside a JWT payload. The signature only proves authenticity, not confidentiality.
What does “malformed JWT” mean? A JWT must have exactly three dot-separated parts, each being valid Base64URL-encoded JSON (for header and payload). Common causes of malformed JWTs include copying only part of the token, URL-encoding the dots, or accidentally including whitespace.
Why is my token expired?
The exp claim contains a Unix timestamp (seconds since January 1, 1970 UTC). If the current time is past this timestamp, the token is expired. Obtain a new token by re-authenticating.
What is the difference between HS256 and RS256? HS256 uses a symmetric secret — the same key signs and verifies the token. RS256 uses an asymmetric key pair — a private key signs and a public key verifies. RS256 is preferred when multiple parties need to verify tokens without sharing a secret.