JWT Decoder & Inspector

Decode JWT header and payload locally, inspect common claims, and review token timing metadata.

Decode only

This tool decodes JWT contents locally but does not verify the signature or trustworthiness of the token.

JWT Decoder: Inspect Tokens Without Shipping Them Anywhere

A JWT decoder is for the moment when you have a token in a header, cookie, or API response and need to see what is actually inside it. Paste a token, split the three segments, decode the header and payload, and inspect claims like sub, aud, iat, and exp without wiring up a library or dropping into a REPL.

This JWT decoder online tool runs entirely in the browser, which matters more than people admit. Tokens often contain user identifiers, tenant IDs, scopes, emails, and internal metadata. If you just need to inspect structure and claims, you should be able to decode JWT token locally instead of pasting it into a service that sends it to a server.

JWTs are compact, easy to pass around, and easy to misuse. Decoding one helps you answer practical debugging questions fast: which algorithm is declared in the header, which issuer minted it, whether the token is expired, and whether the audience matches the service that's rejecting it.

What a JWT decoder actually shows you

A JSON Web Token usually has three dot-separated parts:

header.payload.signature

The header and payload are Base64URL-encoded JSON. A decoder turns those two segments back into readable objects. The signature stays opaque unless you're verifying it with the signing secret or public key.

That distinction matters. Decoding is inspection, not trust. If a payload says "role":"admin", that only tells you what the token claims. It does not prove the token is valid, signed by the right issuer, unexpired, or intended for your app.

Using it

Paste the full token into the input, then click Decode Token. The tool splits the token on . and decodes the header and payload locally. If you edit the token after decoding, the previous result clears so you can decode the new value deliberately. Read the claims, copy the parsed JSON if needed, and check timestamps like iat, nbf, and exp against the current time.

If you're debugging a broken auth flow, start with the header. {"alg":"HS256","typ":"JWT"} tells you what the issuer expected to sign with. Then inspect the payload for claim mismatches such as the wrong aud, missing scope, or an iss that doesn't match the environment.

When you'd actually reach for a JWT decoder

An API returns 401 and you need to confirm whether the token is expired or not yet valid
A frontend app sends the wrong audience and you want to compare aud against the backend's expectation
You're integrating OAuth or OpenID Connect and need to inspect iss, sub, azp, or provider-specific claims
A staging environment issues tokens with a different signing algorithm than production and you need to spot it quickly
You're checking whether a custom claim like permissions or tenant_id is present before blaming auth middleware

JWT structure and claim basics

The header is usually small: algorithm, token type, sometimes a key ID (kid). The payload carries claims. Some are standardized, some are application-specific.

The standard claims you'll see most often:

iss - issuer
sub - subject, usually the user or service identity
aud - intended audience
exp - expiration time as a Unix timestamp
nbf - not valid before
iat - issued at
jti - token ID

Custom claims are where most real debugging happens. Examples include role, scope, org_id, or feature_flags. A JWT decoder is useful because it lets you inspect those fields without writing code like JSON.parse(atob(token.split('.')[1])) and then remembering that JWTs use Base64URL, not standard Base64.

Decoding vs verifying

This is the mistake that causes bad security decisions: a decoded JWT is readable, but it is not automatically trustworthy.

Decoding answers "what does this token say?" Verification answers "was this token signed by someone I trust, with the algorithm and key I expect, and is it still valid for this audience and time window?"

If you're inspecting a token during development, decoding is usually enough. If you're making an authorization decision in an app, verification is mandatory. Never treat decoded claims as authoritative until signature, algorithm, issuer, audience, and time-based claims have been validated.

Troubleshooting

My JWT decoder says the token is invalid JSON — One of the first two segments is not valid Base64URL-decoded JSON. Check for a truncated token, an extra quote, or a token format that is not actually JWT.

The payload won't decode in another Base64 tool — JWTs use Base64URL, not standard Base64. - and _ replace + and /, and padding is often omitted.

The token looks readable but my API still rejects it — Decoding is not verification. The signature may be wrong, the issuer may be untrusted, the audience may not match, or the token may be outside its nbf / exp window.

exp looks like a random number — It's usually a Unix timestamp in seconds. 1712592000 is a date, not a duration.

Can I decode JWT token locally without uploading it? — Yes. This tool runs in the browser, so the token can be inspected locally instead of being sent to a remote decoder service.