JWT Decoder & Inspector
Paste a JSON Web Token to instantly decode the header, payload, and claims. See expiry status, plain-English claim notes, and structure validation — 100% in your browser.
| Claim | Value | Description |
|---|
How to use
- Paste your JWT into the box — the tool decodes it automatically as you type.
- Read the panels: Header shows the algorithm and token type. Payload shows all claims as formatted JSON.
- Check the expiry badge — green means valid, red means expired, yellow means not-yet-valid.
- Claims table maps each key to its plain-English meaning per RFC 7519.
Frequently asked questions
Is my JWT token sent to a server?
No. This tool decodes your JWT entirely in your browser using JavaScript. Open DevTools → Network while you paste a token — you will see zero outbound requests from the tool. Your token never leaves your tab.
What are the three parts of a JWT?
A JWT is three base64url-encoded strings separated by dots: HEADER.PAYLOAD.SIGNATURE. The header describes the algorithm (e.g. HS256, RS256) and token type. The payload contains the claims. The signature verifies the token was not tampered with.
What does the exp claim mean?
The exp (Expiration Time) claim is a Unix timestamp in seconds after which the token must not be accepted. This tool shows it as a human-readable date and tells you whether the token is currently valid, expired, or not yet active.
Can this tool verify the JWT signature?
This tool verifies structure only — three dot-separated base64url sections with valid JSON header and payload. Cryptographic signature verification requires the secret key (for HS256) or the public key (for RS256/ES256) and must be done server-side.
What is the difference between iat, nbf, and exp?
iat (Issued At) records when the token was created. nbf (Not Before) is an optional timestamp before which the token must not be accepted — useful for delayed-activation tokens. exp (Expiration Time) is when the token stops being valid. All three are Unix timestamps in seconds.
What are the standard registered JWT claims?
RFC 7519 defines seven: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration Time), nbf (Not Before), iat (Issued At), and jti (JWT ID). Applications add private claims — email, name, role, scope, and so on.
Why does my token say expired?
The exp claim in your token is a Unix timestamp in the past. JWTs are stateless — once exp is past, the token is invalid regardless of session state. To get a fresh token, log in again or exchange a refresh token if your auth system supports it.
Is base64url the same as base64?
Base64url is a URL-safe variant: it replaces + with - and / with _, and omits = padding, so JWTs can be embedded in URLs and HTTP headers without encoding issues. This tool handles base64url decoding natively in JavaScript — no library needed.
Can I decode an encrypted JWT (JWE)?
No. This tool decodes signed JWTs (JWS). An encrypted JWT (JWE) has five dot-separated parts and an encrypted payload you cannot read without the private key. If your token has four dots instead of two, it is a JWE.
How do I read a JWT without the secret key?
The header and payload are only base64url-encoded, not encrypted — anyone with the token can read the claims without any key. The signature prevents tampering but not reading. Never put sensitive data (passwords, SSNs) in a JWT payload.
Examples
Standard OAuth2 access token
Typical token from an OIDC server. sub is the user ID; exp is 1 hour after issue.
Header: {"alg":"RS256","typ":"JWT","kid":"abc123"}
Payload: {"iss":"https://auth.example.com",
"sub":"user_01HXYZ",
"aud":"api.example.com",
"iat":1748736000,
"exp":1748739600,
"email":"jane@example.com",
"role":"admin"}
Debugging a 401 Unauthorized
Paste the token from the failing request here. The expiry badge shows exactly how long ago it expired — faster than manual epoch math.
exp: 1716163200 → 2024-05-20 00:00 UTC Now: 2026-06-01 07:00 UTC Expired: ~382 days ago Fix: request a fresh token
Reading claims without the secret
You don't need the signing key to read payload claims. Try the canonical example from jwt.io:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 .eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6 IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
About JWT decoding
JSON Web Tokens (JWTs, pronounced "jot") are an open standard (RFC 7519) for transmitting information as a digitally signed JSON object. They are the most common format for access tokens in modern web authentication — OAuth 2.0 servers issue them, APIs accept them, and developers debug them constantly.
A JWT has three dot-separated parts, each base64url-encoded. The header names the signing algorithm (alg) and token type (typ). The payload contains claims — key-value pairs asserting facts about the subject (the user or service) and the token itself. The signature is computed over the encoded header and payload using a secret or private key, allowing the receiver to verify the token has not been altered.
The key insight that trips up developers: the payload is encoded, not encrypted. Anyone who possesses the token can base64url-decode the payload and read every claim. Security comes from the signature proving the payload was not tampered with — not from secrecy of the payload. Never put a password, SSN, or anything sensitive in a JWT payload.
The registered claim names (iss, sub, aud, exp, nbf, iat, jti) are intentionally terse — three characters — to keep token size small, since JWTs travel in every HTTP Authorization header. A typical access token is 300–600 bytes; verbose claim names would inflate every request.
The expiry (exp) and not-before (nbf) claims use Unix timestamps (integer seconds since 1970-01-01T00:00:00 UTC). This tool converts them to human-readable local time and computes how long until expiry or how long since expiry — the most common thing a developer needs when debugging a 401 response.
This tool performs pure structural decoding: it splits on dots, base64url-decodes the first two parts, and JSON-parses them. No HTTP requests are made. You can safely paste production tokens without risk of logging or transmission. For cryptographic signature verification, use a server-side library such as jsonwebtoken (Node.js), PyJWT (Python), or System.IdentityModel.Tokens.Jwt (.NET) with the appropriate signing key.