🔑 JWT Decoder
Decode any JSON Web Token instantly. Inspect header, payload & all claims. Check expiry, visualize token lifetime & understand every field — free, 100% client-side.
Paste a JWT token above to decode it
Works with access tokens, ID tokens, refresh tokens, and any standard JWT from any provider.
Everything a Developer Needs to Inspect JWTs
From quick expiry checks to deep claim inspection — built for debugging auth flows and understanding token security.
Instant Decoding
Paste any JWT and see header, payload, and signature decoded immediately — no submit button needed.
Syntax Highlighting
JSON output with color-coded keys, strings, numbers, and booleans for easy reading.
Validity Checker
Automatically checks exp, iat, and nbf claims to tell you if the token is valid, expired, or expiring soon.
Token Timeline
Visual timeline from token issue time (iat) to expiry (exp) with live now-marker.
Algorithm Info
Shows the signing algorithm with a security rating — flags dangerous 'none' algorithm tokens.
Claims Reference
Explains every standard JWT claim (iss, sub, aud, exp, iat, jti) in plain English.
100% Private
All decoding happens in your browser — your token is never sent to any server.
Token Stats
Token size, number of claims, algorithm, age, and time-to-expiry at a glance.
Copy Sections
One-click copy for the decoded header JSON, payload JSON, or the full token.
Who Uses This JWT Decoder?
Backend developers, frontend engineers, security auditors, and developers learning OAuth2 & OpenID Connect.
Debug Auth Issues
Quickly inspect what claims your server is putting in tokens and why certain requests are failing.
Inspect API Responses
See exactly what user data your OAuth provider or identity platform encodes in the access token.
Check Token Expiry
Paste a token from logs or network traffic to see if it was still valid at the time of an error.
Learn JWT Structure
Perfect for understanding how JWTs work — see what's inside tokens from Auth0, Firebase, AWS Cognito, and more.
Build Auth Flows
Verify your token generation code is including all required claims before deploying to production.
Audit Token Permissions
Review scope, role, and permission claims to understand what level of access a token grants.
Frequently Asked Questions
Everything you need to know about JWT structure, security, claims, and how to use this decoder.
What is a JWT (JSON Web Token)?
A JWT (JSON Web Token) is a compact, URL-safe token format used to securely transmit information between parties. It consists of three Base64URL-encoded parts separated by dots: Header (algorithm and token type), Payload (claims/data), and Signature (to verify authenticity). JWTs are widely used for authentication and authorization in web APIs.
Is it safe to decode a JWT token online?
This tool decodes JWTs entirely in your browser — no data is ever sent to our servers. However, you should still avoid pasting production tokens containing sensitive user data into any online tool. Use sample tokens or tokens from test environments for debugging. The payload of a JWT is only Base64URL encoded, not encrypted, so anyone with the token can read its contents.
Can you verify a JWT signature with this tool?
This tool can decode the JWT and display all claims, but it cannot verify the cryptographic signature without the secret key (for HS256) or the public key (for RS256/ES256). Signature verification must be done server-side. The tool does flag tokens using the 'none' algorithm (unsigned) as insecure.
What are the standard JWT claims?
Standard JWT claims include: iss (Issuer — who created the token), sub (Subject — who the token represents, usually a user ID), aud (Audience — who the token is for), exp (Expiration — when the token expires, as a Unix timestamp), nbf (Not Before — token not valid before this time), iat (Issued At — when the token was created), and jti (JWT ID — unique identifier for the token).
Why does a JWT have 3 parts separated by dots?
A JWT has 3 Base64URL-encoded parts: (1) Header — specifies the algorithm (e.g., HS256) and token type. (2) Payload — contains the claims (user data, expiry, issuer, etc.). (3) Signature — a cryptographic hash of header + payload, created with a secret/private key. The dots separate these parts: header.payload.signature. This structure lets anyone decode and read the header and payload, but only parties with the key can verify the signature.
What JWT algorithms are supported?
Common JWT algorithms include: HS256/HS384/HS512 (HMAC-SHA — symmetric, uses a shared secret), RS256/RS384/RS512 (RSA — asymmetric, private key signs, public key verifies), ES256/ES384/ES512 (ECDSA — elliptic curve, more efficient than RSA), PS256/PS384/PS512 (RSA-PSS — RSA with probabilistic signature). The 'none' algorithm (no signature) is dangerous and should never be accepted in production.
What does 'Bearer token' mean?
A Bearer token is an access token passed in the HTTP Authorization header as 'Authorization: Bearer <token>'. In modern APIs, this is almost always a JWT. The term 'Bearer' means anyone who bears (possesses) the token can use it — no additional proof of identity is needed. This is why JWTs must be kept secret and have short expiry times.
What is the exp claim and how does JWT expiry work?
The 'exp' (Expiration Time) claim is a Unix timestamp (seconds since Jan 1, 1970 UTC). After this time, the JWT must be rejected. For example, exp: 1700000000 means the token expired on November 14, 2023. Servers should always validate the exp claim before accepting a token. Short expiry times (15 min to 1 hour) are recommended for access tokens.
What is the difference between JWT and session tokens?
Session tokens are random strings stored in a database — the server looks them up on every request. JWTs are self-contained — the server can verify them without a database lookup using the signature. JWTs are stateless, making them ideal for microservices and APIs. However, JWTs cannot be easily revoked before expiry, while session tokens can be deleted from the database instantly.
What is the difference between JWT and JWE (encrypted JWT)?
A standard JWT (JWS — JSON Web Signature) only signs the payload — the data is Base64URL encoded but NOT encrypted. Anyone can read the payload contents. JWE (JSON Web Encryption) encrypts the payload so it can only be read by the intended recipient. JWE tokens look different: they have 5 parts instead of 3. Always use HTTPS to transport JWTs to prevent interception.
Why is 'alg: none' dangerous in JWT?
The 'none' algorithm means the JWT has no signature. An attacker can craft any payload they want, set alg to 'none', and present it as valid. Servers that accept the 'none' algorithm can be tricked into granting unauthorized access. Never accept tokens with alg: none in production — always require and validate signatures.
How do I check if a JWT is expired?
Paste the JWT into this decoder and check the 'exp' (Expiration) claim. The tool automatically compares it to the current time and shows a clear status: ✓ Valid, ✗ Expired, ⚠ Expiring Soon, or ∞ No Expiry. Programmatically: decode the payload, read the 'exp' field, and compare with Math.floor(Date.now() / 1000).