A JSON Web Token (JWT) is a compact, URL-safe string made of three Base64-encoded parts separated by dots: a header (algorithm), a payload (claims), and a signature. It is widely used for authentication and authorization in APIs.

Does decoding verify the JWT signature?

No. Decoding reads the header and payload without verifying the signature. To verify a JWT you need the secret key or public key that was used to sign it. This tool is for inspection only.

What claims should I check in a JWT?

Key claims to inspect: exp (expiry time), iat (issued at), nbf (not before), iss (issuer), sub (subject/user ID), and aud (audience). Always check exp to confirm the token has not expired.

Free Online JWT Decoder & Inspector

Paste any JWT token and instantly decode its header and payload sections. Inspect claims, expiry times, and issuer information without needing the secret key.

Understanding JWTs: Why Decoding Matters for Security

JSON Web Tokens have become the dominant mechanism for authentication and authorization in modern web applications. From single page apps authenticating against REST APIs to microservice architectures where services need to verify each other's identity, JWTs are everywhere. Despite their ubiquity, many developers work with JWTs for years without fully understanding their structure, what the encoded data contains, and what the security implications of different implementation choices are. Being able to decode and inspect a JWT is a foundational skill for anyone building or securing web systems.

What Is a JSON Web Token?

A JSON Web Token is a compact, self-contained way to securely transmit information between parties as a JSON object. The standard is defined in RFC 7519 and is widely supported across virtually every programming language and framework. JWTs are designed to be stateless: all the information the receiving party needs to verify the token and understand the user's identity or permissions is encoded within the token itself. This eliminates the need for the server to query a database or session store on every request, making JWT based systems highly scalable.

The "web" in JSON Web Token reflects its primary use case: HTTP based API authentication. When a user logs in, the server generates a JWT containing claims about the user's identity and permissions, signs it with a secret key or private key, and sends it to the client. The client stores the token typically in memory, a cookie, or localStorage and sends it in the Authorization header of subsequent requests. The server validates the token's signature and extracts the claims, without needing to look up session data. This pattern scales well across distributed systems and multiple server instances.

The Three Parts of a JWT

Every JWT consists of three Base64url-encoded sections separated by dots: the header, the payload, and the signature. The header is a JSON object specifying the token type (typ: "JWT") and the signing algorithm (alg), such as HS256 (HMAC with SHA-256) or RS256 (RSA with SHA-256). The payload is a JSON object containing claims statements about an entity, typically the authenticated user. Standard claims include sub (subject), iat (issued at), exp (expiration time), and iss (issuer). Custom claims can carry application specific data like user roles or subscription tier.

The signature is the critical security component. It is computed by taking the Base64url encoded header, a dot, the Base64url encoded payload, and signing the result using the algorithm specified in the header and the server's secret or private key. This signature ties the header and payload together: any modification to either section even changing a single character invalidates the signature, making the tampering immediately detectable. The verification step on the server simply recomputes the expected signature and compares it to the one in the token. If they match, the token is authentic and the claims can be trusted.

Why Decoding JWTs Is Critical

Decoding a JWT reveals the plaintext JSON contained in the header and payload sections. This is invaluable for debugging: you can see exactly what claims the token contains, when it was issued, when it expires, what roles or permissions are encoded, and which algorithm was used to sign it. When users report authentication failures or permission errors, decoding the token they received is often the fastest way to diagnose the problem. Maybe the token expired hours ago, the user's role claim is incorrect, or the subject claim doesn't match the expected user identifier format.

Decoding is also essential when integrating with third party identity providers. OAuth 2.0 and OpenID Connect flows issue ID tokens and access tokens as JWTs. Understanding the claims structure of these tokens which may vary between providers like Google, Auth0, Okta, or Azure AD is necessary to correctly extract user information, validate audience restrictions, and implement role based access control. A decoder lets you inspect tokens in real time during integration development without writing any code, dramatically accelerating the integration process.

Security Considerations When Using JWTs

The most critical security principle with JWTs is that decoding is not the same as verification. Anyone can decode the header and payload of a JWT they are merely Base64url encoded, not encrypted. What makes a JWT secure is the signature verification step, which requires access to the signing key. Client-side code that decodes a JWT to read user claims must never rely on those claims without server side signature verification. A malicious user could manually construct a JWT with arbitrary claims; only signature verification confirms the token genuinely came from your server.

Algorithm confusion attacks are a well known JWT vulnerability. Some early JWT libraries accepted the alg header value from the token itself when selecting the verification algorithm. An attacker could set alg to "none" and send a token with no signature, which these libraries would accept as valid. Modern libraries and implementations address this by requiring the application to explicitly specify which algorithms are acceptable for verification, ignoring the algorithm claimed in the token header. Always configure your JWT library to accept only the specific algorithm your application uses and reject all others.

Debugging Authentication Issues with JWT Inspection

A systematic approach to JWT debugging starts with decoding. When a user cannot access a resource, check whether they have a token at all, then decode it to verify the key claims: Is the token expired (check exp against the current timestamp)? Does the iss (issuer) match your expected identity provider? Does the aud (audience) match your application's identifier? Is the sub (subject) or user ID claim what you expect? Does the token contain the role or permission claims your authorization logic requires? These questions cover the vast majority of JWT related authentication failures.

Token expiry is particularly important to handle gracefully in client applications. JWTs should have short expiry times minutes to hours, not days to limit the damage if a token is intercepted. Client applications should implement token refresh logic that proactively exchanges an expiring token for a new one before users experience authentication failures. Inspecting the exp claim during development helps you tune expiry times appropriately and test that your refresh logic triggers at the right threshold. A JWT decoder that displays the expiry time in human readable format makes this verification instant and intuitive.