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.

What happens after exp: the refresh cycle

Why would anyone issue a token that expires? Short lifetimes limit how long a stolen bearer token stays dangerous, so issuers pair the access token with a second, longer-lived refresh credential whose only job is obtaining new access tokens when the current one expires.⁷ A client that suddenly starts collecting 401s after a period of working usually hit an access token whose exp passed between refreshes: the failure is the design doing its job, not a mystery. The interesting question is why the refresh stopped happening, and the answer lives in the client, not the token.

Decode the failing access token and read iat together with exp. A stale iat sitting next to an expired exp means the token was issued long before its final rejection, so the refresh step stopped happening some time ago; a fresh iat next to a near-term exp means the loop is working and the expiry is ordinary. The refresh credential itself is a different token with a different lifetime and often a different format, so the two are decoded and reasoned about separately, never compared field for field. Paste each into the inspector on its own and read its own claims.

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.⁸

The header is a claim, not a fact

The alg header states what the issuer claims to have used, and it travels inside the signed message, so a verifier must decide its own expected algorithm rather than following the header's suggestion. A real class of attacks works exactly that way: switching the header to none, or to a different family than the verifier assumed, lets a permissive library validate with the attacker's chosen math instead of the issuer's.⁹ The defense is to pin the expected algorithm on the verifying side and reject anything else. A header you can read is not a header you can trust.

Reading the header here is safe by design. The inspector displays alg and typ as decoded data and never acts on either, which is exactly how these fields should be read by a debugging tool. For troubleshooting, the displayed algorithm is the starting point of the HS-versus-RS choice your system made, and of any mismatch between what your provider issues and what your verifier expects; a token claiming HS256 in a system configured for RS256 keys fails in ways this panel makes obvious before you touch a server log. Nothing on this page validates a token; every field here just informs you.

The kid header and the key set

Asymmetrically signed tokens commonly carry a kid (key ID) in the header, naming which of the issuer's keys produced the signature. Issuers rotate keys and publish several at once, so the header's kid is the piece that tells a verifier which key to try, rather than assuming one key forever.¹⁰ When a token that used to verify suddenly stops after the issuer rotated keys, a key-set mismatch is the first thing to check, and the header panel above shows the token's own kid the moment you paste it. Match that value against the issuer's published set and you know which side of the rotation the token predates.

The key set is the other half of the mechanism. A JWKS is a JSON document, published by the issuer, that lists the current public keys; each entry can carry its own kid, so a verifier fetching the document can find exactly the key this token's header names.¹⁰ That is what the earlier verification walkthrough means by fetching the issuer's public keys: one document, several keys, matched by identifier. Decoding the header here shows which kid a token claims, which is the first value to match against that set when signature verification fails.

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.

Provider-specific claim shapes

Beyond the standard seven, identity providers layer their own conventions on top. Custom claims arrive namespaced under collision-resistant keys so they never collide with registered names;⁵ role and permission arrays appear in provider-specific shapes; and separate token types carry access versus identity, each with a different claim layout. The standard names keep their exact meaning no matter who issued the token, while everything an individual provider adds lands in its own namespaced keys. That division is what lets one inspector read tokens from any issuer: the shared core is predictable, and the rest is decoration you can look up in the provider's own documentation.

The inspector earns its keep on provider differences. Paste a token from a working session and one from the broken session of the same flow, and compare the claim sets side by side: provider-specific problems surface as claim-level diffs, a missing namespace, a swapped token type, a role array that changed shape. That comparison is the fastest route from a provider's documentation to what it actually put in your token, because the docs describe the layout while the decoded payload is the layout. Two pastes and a glance usually beat an hour of log spelunking.

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.

Reading a Token with the JWT Inspector

Most authentication bugs come down to one question: what did the issuer actually put in the token? You can answer it without the signing key, because the header and payload are only Base64Url-encoded. The guide below covers what each decoded section shows, how the header differs from the payload, when a browser inspector is the right tool and what it cannot tell you about whether a token is valid.

Decoding in your own code

The decode this tool performs is three steps: split the token on the dots, Base64Url-decode the first two parts, and parse each as JSON. Every mainstream language can do that in a few lines without any library, which is why decoding is never the hard part of JWT work. Every language also ships JWT libraries, and their extra value is exactly the step this page deliberately does not perform: verification, where the key or key set enters the call and the signature is actually checked. Decode anywhere; verify where the keys and the authority live.

The boundary follows from what decoding needs: no secret. A decoder, in any language, proves nothing about who wrote the token, which is why a library call that only decodes is no more authoritative than this inspector. The library earns its keep at the verify call, where the signature is checked against a key you chose and the claims are checked against rules you wrote. Keep debugging with decoders, including this one, and gate access with verifiers. Confusing the two roles is how unverified claims end up trusted in production code.