JWT Decoder Free Online
Free online JWT decoder. Paste any JWT token to instantly view its header, payload and expiry. No key needed.
JSON Web Tokens (JWTs) are the most widely used standard for authentication and authorisation in modern web applications and APIs. If you work with REST APIs, OAuth, single sign-on systems, or any modern authentication framework, you will encounter JWTs regularly. This free JWT decoder lets you instantly decode any JWT to see its header, payload, and claims - no library, no server, no account required. Everything runs in your browser for complete privacy.
How to Use the JWT Decoder
Copy your JWT token
Find the JWT you want to inspect. JWTs are typically found in browser developer tools (Application tab → Cookies, or Network tab → Authorization headers), in API response bodies, in your code as environment variables or configuration values, or in log files during debugging. A JWT is a long string starting with "eyJ" (the Base64URL encoding of {"alg") followed by two dots separating three sections.
Paste into the decoder
Paste the complete JWT string into the input field. The decoder automatically detects the three sections separated by dots and decodes each one. You do not need to split the token manually - paste the entire token including all three parts (header.payload.signature).
Inspect the decoded header and payload
The header JSON shows the signing algorithm (alg) and token type (typ). The payload JSON shows all the claims - the actual data encoded in the token. Common claims include: sub (subject/user ID), email, name, iat (issued at timestamp), exp (expiration timestamp), aud (audience), and iss (issuer). The tool also translates Unix timestamps to human-readable dates for exp, iat, and nbf claims.
What Is a JSON Web Token (JWT)?
A JSON Web Token is a compact, URL-safe token format defined by RFC 7519. It encodes a set of claims (pieces of information) in a JSON object that is digitally signed to prevent tampering. JWTs are used most commonly for:
Authentication - after a user logs in, the server creates and signs a JWT containing the user's identity and sends it to the client. The client includes this JWT in the Authorization header of subsequent API requests. The server verifies the JWT's signature to authenticate the request without needing to look up the session in a database.
Authorisation - JWTs can include permission scopes and roles in their payload claims, allowing the server to determine what the authenticated user is allowed to do based solely on the token content, without additional database lookups.
Information exchange - signed JWTs can securely transmit information between parties because the signature guarantees the payload has not been tampered with.
The Three Parts of a JWT
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature.
Header - a JSON object containing two fields: alg (the signing algorithm, such as HS256 for HMAC-SHA256 or RS256 for RSA-SHA256) and typ (always "JWT"). The header tells the recipient how to verify the token's signature.
Payload - a JSON object containing the claims. Claims are statements about an entity (typically the user) and additional metadata. Standard registered claims include: iss (issuer), sub (subject - typically the user ID), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Applications add additional custom claims as needed.
Signature - created by taking the encoded header and payload, joining them with a dot, and signing with the algorithm specified in the header using a secret key (for HMAC algorithms) or private key (for RSA/ECDSA algorithms). The signature prevents the token from being tampered with - any change to the header or payload invalidates the signature.
Important Security Notes About JWTs
The payload of a JWT is encoded with Base64URL, which is not encryption - it is simply encoding. Anyone who has the JWT can decode it and read the payload without any key. This decoder demonstrates that clearly. This means you should never include sensitive information (passwords, credit card numbers, private data) in a JWT payload - assume the payload can be read by anyone who has the token.
This tool decodes JWTs but does not verify their signatures, because signature verification requires the secret key or public key used to sign the token. Decoding without verification is useful for debugging and inspecting token contents, but you must always verify JWT signatures in your application code before trusting the claims in a token.
Common JWT Claims Explained
sub (Subject) - the principal that the JWT is about, typically a user ID or username.
iss (Issuer) - identifies who created and signed the JWT, typically an authentication server URL or service name.
aud (Audience) - identifies the recipients the JWT is intended for. APIs typically verify that their own identifier appears in the aud claim.
exp (Expiration Time) - a Unix timestamp after which the token must be rejected. The decoder converts this to a human-readable date/time for easy inspection.
iat (Issued At) - the Unix timestamp when the token was created. Also shown as a human-readable date by this decoder.
nbf (Not Before) - a Unix timestamp before which the token must be rejected. Rarely used.
jti (JWT ID) - a unique identifier for the token, used to prevent replay attacks by checking against a list of used token IDs.
OAuth 2.0 and JWTs - Access Tokens and ID Tokens
JWTs are the standard format for tokens in OAuth 2.0 and OpenID Connect authentication flows. Understanding the difference between access tokens and ID tokens is critical:
Access tokens are credentials used to access protected resources (APIs). In OAuth 2.0, access tokens can be in any format, but JWTs are the most common because they are self-contained - the API can verify the token and extract user information without calling back to the authentication server. Access tokens typically have short lifetimes (15 minutes to 1 hour) and include scopes indicating what permissions the bearer has.
ID tokens (OpenID Connect) are JWTs that contain identity information about the authenticated user. They are issued during login and contain claims like sub (user ID), email, name, and authentication time. ID tokens are meant for the application to learn who the user is, not for API authentication (though they are sometimes misused this way).
Refresh tokens are long-lived credentials (days, weeks, or months) used to obtain new access tokens when the current access token expires. Refresh tokens are usually opaque strings (not JWTs) and must be stored securely. The flow is: user logs in → receives access token + refresh token → access token expires → client sends refresh token to auth server → receives new access token.
Example OAuth 2.0 JWT access token payload:
{
"iss": "https://auth.example.com",
"sub": "user123",
"aud": "https://api.example.com",
"exp": 1735689600,
"iat": 1735686000,
"scope": "read:profile write:posts"
}
JWT Security Vulnerabilities and Best Practices
JWTs have several known security pitfalls. Here are the most critical ones and how to avoid them:
The "alg: none" attack: The JWT specification allows "none" as a signing algorithm for unsigned tokens. Some poorly implemented JWT libraries do not validate that the token uses a proper algorithm - an attacker can change "alg":"HS256" to "alg":"none" in the header, remove the signature, and the vulnerable library accepts the token as valid. Mitigation: always specify which algorithms your application accepts (algorithm allowlisting) and reject "none" explicitly.
Algorithm confusion (HS256 vs RS256): If an API expects RS256 (RSA signature, verified with public key) but an attacker sends HS256 (HMAC signature), some libraries will use the RS256 public key as the HMAC secret. Since the public key is public, the attacker can sign their own tokens. Mitigation: always specify exactly which algorithm you expect and reject others.
Missing expiration checks: Always verify the exp claim. A token without expiration or with no expiration verification can be used indefinitely even if the user's permissions have been revoked. Mitigation: require exp claim and reject tokens where current time > exp.
Weak signing secrets: For HS256 tokens, the secret must be strong (32+ random bytes). Short or predictable secrets can be brute-forced. Mitigation: use a cryptographically random 256-bit secret, never a dictionary word or password.
Storing sensitive data in the payload: Remember the payload is only Base64-encoded, not encrypted. Anyone with the token can read it. Never include passwords, credit card numbers, PII, or other sensitive data. Mitigation: only include non-sensitive identifiers and claims.
No token revocation mechanism: JWTs are stateless - the server does not track issued tokens. If a token is compromised or a user's access is revoked, the token remains valid until expiration. Mitigation: use short expiration times (15-60 minutes) for access tokens and implement refresh token rotation with revocation support.
JWT vs Session Cookies - When to Use Each
JWTs and traditional session cookies solve similar problems but have important trade-offs:
Session cookies (stateful):
The server generates a random session ID (like "a8f3d2c1b9e7"), stores it in a session store (Redis, database, in-memory), and sends it to the client as a cookie. The session store maps the session ID to user data (user ID, permissions, shopping cart). On each request, the server looks up the session ID to retrieve the user's data.
Advantages: Can be instantly revoked (delete the session from the store), session data is server-side so clients cannot read it, no size limits on session data. Disadvantages: Requires server-side state (session store), harder to scale horizontally (all servers need access to the same session store), requires database or cache lookup on every request.
JWTs (stateless):
The server creates a JWT containing user ID and permissions, signs it, and sends it to the client. On each request, the server verifies the JWT signature and trusts the claims inside without any database lookup. All information is in the token.
Advantages: No server-side state needed, easily scales horizontally (any server can verify any token), no database lookup required for authentication, works across multiple domains. Disadvantages: Cannot be revoked before expiration (unless you add a token denylist, which reintroduces state), payload is readable by client, larger than session cookies (JWTs are typically 500-1000 bytes), vulnerable to XSS if stored in localStorage.
When to use JWTs: Microservices architectures where multiple services need to verify tokens without shared session state, mobile apps, single sign-on (SSO) across domains, public APIs. When to use sessions: Traditional server-rendered web apps, when you need instant logout/revocation, when session data is large or sensitive.
Hybrid approach: Many systems use both - JWTs for stateless API access with short expiration (15-60 minutes) plus refresh tokens stored in HttpOnly cookies that allow revocation.
Debugging JWT Issues - Common Error Messages
"Invalid signature" - the token's signature does not match the computed signature. Causes: wrong secret key on the server, token was tampered with, algorithm mismatch (token signed with HS256 but server verifying with RS256). Solution: use this decoder to inspect the header's "alg" value and verify the server is using the correct secret/key for that algorithm.
"Token expired" - the current time is past the exp claim. Causes: clock skew between client and server, token genuinely expired. Solution: decode the token to see the exp timestamp and compare to current time. Implement clock skew tolerance (5 minutes) in your verification logic.
"Invalid issuer" - the iss claim does not match the expected value. Causes: token issued by a different auth server, misconfigured issuer URL. Solution: decode the token and compare the iss claim to what your application expects.
"Invalid audience" - the aud claim does not include your API's identifier. Causes: token intended for a different API, misconfigured audience. Solution: decode the token and check if your API's URL or identifier is in the aud claim (can be a string or array).
"Token cannot be used before nbf" - the current time is before the nbf (not before) claim. Causes: clock skew, token issued with future nbf. Rare in practice. Solution: decode to check nbf timestamp.