Decode JWT tokens instantly to inspect headers, payloads, and signatures. Check expiration, verify claims, and debug authentication issues — for free.
JSON Web Tokens (JWTs) are the backbone of modern authentication and authorization. If you've ever logged into a web app and received a token in your browser's localStorage or an HTTP-only cookie, that was almost certainly a JWT. But when something goes wrong — a token is expired, a claim is missing, or the signature doesn't match — you need to see what's inside. Our free online JWT decoder lets you paste any JWT and instantly see its decoded header, payload, and signature, along with expiration warnings and claim analysis.
This guide covers how JWTs work, what each part contains, and how to use our decoder to debug authentication issues effectively.
A JWT is a compact, URL-safe means of representing claims to be transferred between two parties. The claims are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected.
Every JWT consists of three parts separated by dots (.):
.
header.payload.signature
Each part is Base64URL-encoded:
// Decoded header { "alg": "HS256", "typ": "JWT" } // Decoded payload { "sub": "1234567890", "name": "Alice Johnson", "role": "admin", "iat": 1712345678, "exp": 1712432078 }
Our JWT decoder is designed for quick inspection and debugging:
exp
All decoding happens in your browser. Your tokens are never sent to any server, making it safe to inspect tokens containing sensitive claims.
After authenticating with Google OAuth, you receive an ID token that looks like this:
eyJhbGciOiJSUzI1NiIsImtpZCI6ImFiYzEyMyJ9.eyJzdWIiOiIxMDI4Mzc0NzE5MzU0MzI2MTcxOTQzIiwiZW1haWwiOiJhbGljZUBleGFtcGxlLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJuYW1lIjoiQWxpY2UgSm9obnNvbiIsImlzcyI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbSIsImF1ZCI6IjEyMy00NTYtNzg5IiwiaWF0IjoxNzEyMzQ1Njc4LCJleHAiOjE3MTIzNDkyNzh9.signature_here
Paste this into our JWT decoder to see the decoded payload, which reveals the user's Google ID, verified email, name, the token issuer (Google), and the audience (your app's client ID).
If your API returns 401 Unauthorized, the most common cause is an expired token. Our decoder checks the exp claim and tells you exactly when the token expired:
401 Unauthorized
// Decoded payload { "sub": "user-123", "exp": 1712345000 // Expired at: Mar 15, 2024, 2:30 PM UTC // Current time: Mar 15, 2024, 3:00 PM UTC // Status: ⚠️ EXPIRED 30 minutes ago }
Many APIs include custom claims for authorization. A decoded payload might look like:
{ "sub": "alice", "role": "editor", "permissions": ["read:posts", "write:posts", "delete:own"], "org_id": "org-456", "iat": 1712345678, "exp": 1712432078 }
Our decoder highlights standard claims (sub, iat, exp) and shows custom claims (role, permissions, org_id) separately, making it easy to understand what data the token carries.
When users report login issues, decoding their JWT reveals whether the token has the right claims, hasn't expired, and was issued by the correct authority. This is often the fastest way to diagnose auth problems.
Before trusting a token, inspect its claims. Check that the iss (issuer) matches your auth server, the aud (audience) matches your application, and the exp (expiration) hasn't passed.
iss
aud
When integrating with OAuth providers (Google, GitHub, Auth0, Firebase), decoding their tokens helps you understand the exact claims available and how to map them to your user model.
During development, you often need to inspect tokens to understand why an API endpoint returns unexpected results. The decoder gives you immediate visibility into what the server sees.
Review tokens to ensure they don't contain excessive claims, have appropriate expiration times, and use strong signing algorithms (avoid none algorithm tokens).
none
Our decoder runs entirely in your browser — the token is never sent to any server. However, be cautious about using third-party decoders with tokens containing highly sensitive data. When in doubt, use browser DevTools or a trusted command-line tool like jwt.io or jq.
jwt.io
jq
Our tool decodes the header and payload but does not cryptographically verify the signature, because that requires the secret key or public key. Signature verification should always happen on your server using a library like jsonwebtoken (Node.js), PyJWT (Python), or your framework's built-in auth middleware.
jsonwebtoken
PyJWT
The payload is Base64URL-encoded (not encrypted — anyone can decode it). The signature is a cryptographic hash of the header and payload using a secret key (HMAC) or public/private key pair (RSA/ECDSA). The signature proves the token hasn't been modified, but the payload is readable by anyone.
Registered claims are predefined by the JWT spec (RFC 7519): iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID). Our decoder recognizes and labels all of these automatically.
sub
nbf
iat
jti
Yes. A signed JWT is technically a JWS (JSON Web Signature). For encryption, you'd use JWE (JSON Web Encryption), which encrypts the payload so it can't be read without the decryption key. Our decoder handles JWS tokens (the most common type).
Beautify the decoded JWT payload for easier reading and sharing.
Manually decode individual JWT parts — header and payload are Base64URL-encoded.
Generate unique jti (JWT ID) claims for your tokens.
Extract JWTs from Authorization headers or cookie strings using regex.
Read more: JSON Formatter Guide · Base64 Guide · Regex Tester Guide