JWT Decoder & Claims Inspector

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe format for representing claims between two parties.¹ It consists of three Base64Url-encoded sections separated by dots: a header naming the algorithm and token type, a payload carrying the claims, which typically include a user ID, a set of roles, an expiry, and any custom fields, and a signature binding the first two parts together so the receiver can verify the token was created by a trusted party.² The format is defined by the IETF in RFC 7519 and is widely used for both authentication tokens and information exchange.

A widely published example token makes the three parts concrete before you paste your own. Pasting eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c into the inspector decodes to a header of {"alg":"HS256","typ":"JWT"} and a payload of {"sub":"1234567890","name":"John Doe","iat":1516239022}, while the third section stays as an opaque signature the tool never attempts to check. This is a well-known public sample token, not a real credential, so it is safe to paste anywhere for testing the decoder.

Structure of a JWT

The header is a JSON object naming the algorithm used to produce the signature and identifying the token as a JWT. The payload is a second JSON object whose members, called claims, carry the information the token exists to convey: for example, who the token is for, what it grants, and when it stops being valid. The signature is a cryptographic hash or digital signature computed over the encoded header and encoded payload, optionally also covering a shared secret or a private key known only to the issuer, which is what makes the token tamper-evident but readable by anyone who holds it.

Where JWTs are used

JWTs are a widely used format for stateless authentication in web APIs.³ When a user logs in, the server issues a JWT. The client sends it with every request (typically in the Authorization: Bearer <token> header), and the server verifies the signature rather than looking up a session in a database.⁴ This bearer-token pattern, defined by RFC 6750, is what lets a single token travel across microservices while centralizing authentication at the issuer.³

Because the token itself carries the claims, the server does not need to keep session state in memory or in a database, which makes JWTs attractive for distributed systems and single sign-on. In those architectures many services must independently accept the same authorization decision without relying on a central session store, and the self-contained nature of the token is what makes that independence possible.

Why decode offline?

Most popular JWT inspection tools are server-backed websites. When you paste a token, the full token, including the signature, is transmitted to a third-party server. For tokens that grant access to production systems, this is a critical security violation: any party that captures your token can impersonate you until it expires.⁴

This tool performs all decoding in your browser using the built-in atob() function and JavaScript's JSON.parse. No token data, no claims, and no metadata are ever transmitted over the network: the Base64Url decoding, JSON parsing, and expiry comparison all happen inside your current browser tab without making any HTTP request to a decoding service. The tool works fully offline once the page has loaded, and reloading it does not re-send any token you previously decoded.

Understanding the exp claim

The exp claim (expiration time) is a NumericDate value, meaning a Unix-style timestamp counting the number of seconds since January 1, 1970 UTC, and the token must not be accepted once the current time is at or after that moment.⁵ The tool compares exp against the current time shown on your device and reports whether the token has expired, along with a human-readable delta that tells you how long ago it expired or how long it has left, which makes the numeric claim immediately legible for debugging.

Not every JWT carries an exp claim. Long-lived service-to-service tokens and static API keys are sometimes issued without one so that they remain valid until explicitly revoked through some other mechanism such as a token blocklist.⁶ When the claim is absent, the inspector displays a clear "No exp claim; token does not expire" message rather than guessing the validity window, so you can tell at a glance whether the token you are inspecting is meant to time out.

Why the signature is not verified

Verifying a JWT signature requires knowledge of the key the issuer used to sign the token: for symmetric HMAC algorithms like HS256 that means the shared secret itself, and for asymmetric algorithms like RS256 and ES256 that means the issuer's public key.² This tool is an inspector rather than a validator. It decodes exactly what is present in the token but it cannot confirm whether the issuing server still considers the token authentic and unrevoked.⁷

Performing real signature validation

To actually verify a token's signature you need to fetch the issuer's public keys, typically from a JSON Web Key Set (JWKS) endpoint, and use a well-maintained library running on the server side where the secret or private validation inputs can stay protected.⁸ The jose library is one widely used option that supports HMAC, RSA, and elliptic curve algorithms and lets you validate the signature, the expiry, the audience, and the issuer in a single call.

Never trust a JWT's claims in a security-sensitive context without first verifying the signature server-side, because decoding a token only reveals what was placed inside it, not whether that content was produced by a party you actually trust or whether the key it was signed with has since been rotated. Treat the inspector as a debugging aid, and treat server-side signature verification and claims validation as the only authoritative gate for letting a request through.

Standard registered claims beyond exp

The JWT specification (RFC 7519) defines seven standard registered claim names, none of which are required, but several of which are widely useful for interoperable token validation.⁶ The inspector shows each claim present in the payload, so you can immediately see which standard claims your issuer includes and which it omits.

Claims that identify the token

The iss (issuer) claim identifies the principal that issued the token, typically a URL matching the authorisation server's base URL, and provides the hint your server uses to find the public key it needs to verify the signature. The sub (subject) claim identifies the principal the token is about, commonly a user ID or an application identifier in your system, and is almost always present because without it a bearer token has no clear owner. The aud (audience) claim identifies which services should accept the token; a token issued for your API should not be accepted by a different service, and correctly validating the audience claim prevents cross-service token replay attacks.⁹

Claims about timing and uniqueness

The nbf (not before) claim sets the earliest time the token is valid, useful for tokens issued slightly ahead of their intended use window. The iat (issued at) claim gives the exact issuance timestamp, letting you calculate how old a token is relative to its expiry and decide when a token has outlived its useful life. The jti (JWT ID) claim provides a unique identifier for the token, enabling server-side token revocation: if your backend stores issued JTIs in a blocklist, it can reject specific tokens before they expire without invalidating all sessions. Despite their usefulness, all seven registered claims are optional, and many issuers omit the ones they do not need.

Debugging authentication flows with the inspector

Authentication bugs often manifest as token-related errors that look identical from the outside but have different root causes. A 401 response could mean the token is expired, the signing algorithm does not match the server's expectation, the audience claim is wrong for this endpoint, or the subject claim contains an ID that no longer exists in your database. Pasting the token into the inspector immediately shows the algorithm, all claims, and whether the token has expired relative to your local clock, eliminating several possibilities at once without writing any debug code. Furthermore, comparing two tokens issued by the same flow, one from a working session and one from a broken session, often reveals the exact claim difference causing the failure.