Paste a JWT token in the editor
to decode it
Paste any JWT and instantly see its decoded header, payload, and signature. All decoding happens in your browser — your tokens never leave your machine.
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It is widely used for authentication and information exchange between services.
A JWT consists of three base64url-encoded parts separated by dots:
| Part | Contents | Example |
|---|---|---|
| Header | Algorithm and token type | {"alg":"HS256","typ":"JWT"} |
| Payload | Claims (data) | {"sub":"user_42","exp":1893456000} |
| Signature | Integrity check | HMACSHA256(header + "." + payload, secret) |
The header and payload are simply base64url-encoded JSON — they are not encrypted. Anyone with the token can read them. The signature verifies that the token was issued by a trusted party and has not been tampered with.
JWTs are most commonly used as Bearer tokens in the HTTP Authorization header. Here is the typical flow:
localStorage, or an httpOnly cookie).Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
exp claim. If both pass, the request is authorized without any database lookup.This stateless design is what makes JWTs popular for microservices and distributed systems — the server does not need to store session state.
The alg field in the JWT header tells you how the signature was created. The two most common algorithms are:
| Algorithm | Type | How it works | When to use |
|---|---|---|---|
| HS256 | Symmetric | Same secret signs and verifies | Single service that both issues and verifies tokens |
| RS256 | Asymmetric | Private key signs, public key verifies | Multiple services — only the auth server holds the private key |
| ES256 | Asymmetric | ECDSA with P-256 curve | Same as RS256 but smaller signatures |
HS256 is simpler to set up but requires every service that verifies tokens to share the same secret. If the secret leaks from any one service, all tokens are compromised.
RS256 is preferred in distributed architectures. The auth server keeps the private key; all other services only need the public key to verify tokens. Leaking the public key is harmless.
Storing tokens in localStorage is risky because any JavaScript on the page can read them, including scripts injected via XSS. httpOnly cookies are the safer default — the browser sends them automatically and JavaScript cannot access them at all.
Decoding a JWT is not the same as verifying it. Reading the payload works without any key. Verification — checking the signature and the exp claim — must happen server-side before trusting anything in the payload. Skipping this step is surprisingly common.
The alg: none vulnerability is a classic. The JWT spec originally allowed an unsigned token by setting alg to none. A crafted token with this header and an arbitrary payload will pass validation in libraries that don't explicitly block it. Always whitelist the algorithm your application expects.
The payload is base64url-encoded, not encrypted. Anyone with the token can read it. Passwords, card numbers, internal system names — none of these belong in a JWT payload.
Short exp values (15–60 minutes) paired with a refresh token are the standard pattern for a reason: JWTs are stateless and cannot be revoked before they expire. A stolen token with a 30-day expiry is usable for 30 days.
The JWT specification defines a set of registered claim names with well-known meanings:
| Claim | Name | Description |
|---|---|---|
iss | Issuer | Who issued the token |
sub | Subject | Who the token is about (usually a user ID) |
aud | Audience | Who the token is intended for |
exp | Expiration | When the token expires (Unix timestamp) |
nbf | Not Before | Token not valid before this time |
iat | Issued At | When the token was issued |
jti | JWT ID | Unique identifier for the token |
Applications can also add any custom claims (e.g. role, email, permissions). This tool automatically labels all registered claims and formats Unix timestamps as human-readable dates.
Yes. All decoding is done entirely in your browser using JavaScript. The token is never sent to any server. You can verify this by checking the browser network tab — no requests are made when you paste a token.
No. Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). This tool only decodes the token — it reads the header and payload without verifying authenticity.
Include it in the Authorization header as a Bearer token: 'Authorization: Bearer <your-token>'. This is the standard convention for REST APIs and is supported by virtually all API frameworks and gateways.
Session tokens are opaque strings — the server stores the session data and looks it up on every request. JWTs are self-contained — the server encodes the data into the token itself and verifies it on every request without a database lookup. JWTs scale better but cannot be invalidated before expiry without extra infrastructure.
It means the token does not contain an exp claim. Such tokens are valid indefinitely unless explicitly revoked. This is common for API keys and service account tokens, but is generally a bad practice for user-facing authentication tokens.
Standard JWTs (JWS — JSON Web Signature) are signed, not encrypted. The payload is base64url-encoded, which is trivially reversible. Never put sensitive data like passwords in a JWT payload. For encrypted tokens use JWE (JSON Web Encryption) instead.
The JWT spec originally allowed alg: none to indicate an unsigned token. A malicious actor can craft a token with alg: none and an arbitrary payload. Vulnerable JWT libraries that accept this will pass the token as valid without checking any signature. Always configure your JWT library to reject alg: none explicitly.
JWS (JSON Web Signature) is what most people call a JWT — the payload is signed but readable by anyone. JWE (JSON Web Encryption) encrypts the payload so only the intended recipient can read it. JWS proves authenticity; JWE proves authenticity and provides confidentiality.
More Tools