Free Online JWT Decoder & Inspector
Decode any JSON Web Token instantly and inspect its header, payload, and signature. Our tool validates token structure, checks expiration status, and displays all standard claims in a readable format. Everything runs in your browser — your tokens never leave your device.
What is a JWT?
A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe token format defined in RFC 7519. JWTs are widely used for authentication, authorization, and secure information exchange between parties. A JWT contains digitally signed claims that can be verified and trusted by the receiving party.
JWTs are self-contained — they carry all the information needed to authenticate a user or authorize a request, without requiring a database lookup on every request. This makes them ideal for stateless, scalable architectures.
JWT Structure: Header.Payload.Signature
A JWT consists of three Base64URL-encoded parts separated by dots:
Header
Specifies the token type (JWT) and the signing algorithm (e.g. HS256, RS256). Tells the verifier how to validate the signature.
Payload
Contains the claims — statements about the user and metadata like issuer, expiration, and subject. This is the main data carrier.
Signature
Created by signing the encoded header and payload with a secret or private key. Ensures the token has not been tampered with.
Standard JWT Claims
JWT defines a set of registered claims (RFC 7519 Section 4.1) with specific meanings:
| Claim | Name | Description |
|---|---|---|
| iss | Issuer | Identifies the principal that issued the JWT (e.g. your auth server URL) |
| sub | Subject | Identifies the subject of the JWT, typically the user ID |
| aud | Audience | Identifies the recipients the JWT is intended for (e.g. your API URL) |
| exp | Expiration | Unix timestamp after which the token must not be accepted |
| iat | Issued At | Unix timestamp when the token was issued |
| nbf | Not Before | Unix timestamp before which the token must not be accepted |
| jti | JWT ID | Unique identifier for the token, used to prevent replay attacks |
Common JWT Use Cases
Authentication
After login, the server issues a JWT that the client sends with each subsequent request to prove identity without re-authenticating.
API Authorization
JWTs carry permissions and roles, allowing APIs to authorize requests by inspecting the token claims without querying a database.
Single Sign-On (SSO)
JWTs enable SSO across multiple domains and services because they are self-contained and can be verified independently.
Microservices
Services pass JWTs between each other to propagate user context and permissions across a distributed system.
OAuth 2.0 / OIDC
OpenID Connect uses JWTs as ID tokens to convey user identity claims from the identity provider to the application.
Secure Data Exchange
JWTs can carry signed (JWS) or encrypted (JWE) payloads for secure, tamper-proof information exchange between parties.
JWT Security Considerations
Always validate the signature
Never trust a JWT without verifying its signature. An unverified token can be forged by anyone.
Check expiration claims
Always validate exp and nbf claims server-side. Expired tokens must be rejected even if the signature is valid.
Use strong signing algorithms
Prefer RS256 or ES256 over HS256 for production. Never use "alg": "none" as it disables signature verification entirely.
Keep tokens short-lived
Use short expiration times (15 minutes to 1 hour) and refresh tokens for longer sessions. This limits the damage window if a token is stolen.
Never store secrets in the payload
JWT payloads are only Base64-encoded, not encrypted. Anyone can decode them. Never put passwords, API keys, or sensitive data in claims.
Protect against token theft
Store JWTs in HttpOnly, Secure, SameSite cookies rather than localStorage to prevent XSS attacks from accessing them.
Frequently Asked Questions
Yes. This tool runs entirely in your browser using JavaScript. Your token is never sent to any server, stored, or logged. You can verify this by checking the network tab in your browser's developer tools.
This tool decodes and displays JWTs but does not verify signatures, as that requires the signing secret or public key. For signature verification, you need the server-side secret (HS256) or the public key (RS256/ES256). We display the signature as a hex string for inspection.
JWS (JSON Web Signature) is a signed JWT — the payload is visible to anyone but tamper-proof. JWE (JSON Web Encryption) is an encrypted JWT — the payload is both tamper-proof and confidential. Most JWTs you encounter are JWS tokens. This decoder works with JWS tokens.
JWT length depends on the number and size of claims in the payload plus the signature algorithm. RS256 signatures are larger than HS256. Avoid putting unnecessary data in the payload — every claim adds to the token size, and tokens are sent with every HTTP request.
The 'none' algorithm means the JWT has no signature and cannot be verified. This was intended for pre-authenticated contexts but is a well-known security vulnerability. Attackers craft tokens with 'alg: none' to bypass signature checks. Always reject tokens with this algorithm in production.
In JavaScript: split the token by '.', then Base64URL-decode each part with atob() after replacing - with + and _ with /. In Python: use PyJWT (import jwt; jwt.decode(token, options={'verify_signature': False})). In most languages, libraries like jose, jsonwebtoken, or java-jwt handle this for you.
Technically yes — the exp claim is optional. However, tokens without expiration are a significant security risk because a stolen token would be valid forever. Always set a reasonable expiration time and use refresh tokens for long-lived sessions.
There is no hard limit in the JWT specification, but JWTs are typically sent in HTTP headers which have practical limits (8KB for most servers, 16KB for some). Keep your JWTs under 4KB for maximum compatibility. If you need more data, store it server-side and reference it by ID in the token.