Skip to content

JWT Decoder

Decode a JSON Web Token to inspect its header, payload, expiry and claims — without sending it anywhere.

Runs in your browserFree, no sign-up

Settings

Results update automatically as you type.

Enter a JWT to get started.

Your result appears here instantly — nothing is uploaded.

About the JWT Decoder

This JWT decoder splits a JSON Web Token on its dots, Base64URL-decodes the header and payload, and shows both as formatted JSON alongside a claims summary. Registered claims are pulled out and made readable: the signing algorithm from the header, the subject, issuer and audience, and the iat, nbf and exp timestamps converted from Unix seconds into UTC date and time, which is usually the thing you actually wanted to know. Decoding happens entirely in your browser and the token is never transmitted, which matters because a bearer token is a live credential. The signature is not verified — that requires a key, and no key should ever be pasted into a web page.

How to use the JWT Decoder

  1. 1

    Paste the token into the JWT box, leaving off the 'Bearer ' prefix if you copied it from an Authorization header.

  2. 2

    Read the Claims panel for the algorithm, subject, issuer, audience and the issued, not-before and expiry times in UTC.

  3. 3

    Inspect the decoded Header and Payload JSON below, and copy either if you need it elsewhere.

  4. 4

    Note the warning panel: decoding proves nothing about whether the token is genuine.

What people use it for

Debugging a 401 from an API

The expiry claim rendered as a readable UTC timestamp settles in seconds whether the token has simply lapsed or whether the fault lies somewhere else entirely.

Checking which scopes or roles a token carries

Authorisation failures are more often a missing scope than a bad token. Reading the payload shows exactly what the identity provider issued.

Confirming an identity provider's configuration

The iss and aud claims tell you which issuer minted the token and which audience it was intended for, the usual culprits in a misconfigured OIDC client.

Three parts, and why the payload is not a secret

A JWT in the compact serialisation defined by RFC 7519 is three Base64URL segments joined by full stops: header, payload and signature. The header is JSON naming the algorithm in alg and usually the type in typ, often with a kid identifying which key was used. The payload is JSON holding the claims. The signature covers the first two segments, computed over the exact string formed by the header, a dot and the payload. Base64URL, defined in RFC 4648 section 5, substitutes hyphen and underscore for the two characters that are awkward in URLs and omits the padding, so the result is safe in a query string. It is an encoding, not encryption. Anyone holding the token can decode the payload in one line of code, which is why a JWT must never carry a password, a card number or anything else confidential. The signature guarantees integrity and origin — that a party holding the key produced this exact payload and nobody altered it since — but it guarantees nothing about confidentiality. If you genuinely need an encrypted token, that is JWE, specified separately in RFC 7516.

Registered claims and the attacks worth knowing about

RFC 7519 section 4.1 registers seven claims: iss for issuer, sub for subject, aud for audience, exp for expiration time, nbf for not before, iat for issued at, and jti, a unique identifier used to detect replay. The three time claims are NumericDate values — seconds since the Unix epoch, not milliseconds, which is the single most common bug when hand-crafting a token. Two classic vulnerabilities are worth understanding. The alg none attack exploits libraries that trust the header's algorithm field: an attacker rewrites the header to declare no algorithm, strips the signature, and a naive verifier accepts the token. The related algorithm confusion attack takes a service verifying RS256 with a public key, changes the header to claim HS256, and signs using that public key as the HMAC secret — which the attacker knows, because it is public. The defence in both cases is identical: your server decides which algorithm it expects and rejects anything else, never reading it from the token. Always verify server-side, always check exp and aud, and treat any token you paste anywhere as compromised.

Tips

  • Prefer an expired or deliberately issued test token when inspecting one; a live access token is a credential in the same class as a password.
  • If the payload decodes but the header does not, you have probably pasted the segments in the wrong order or dropped a character.
  • An exp that reads as a date in 1970 means your issuer is emitting milliseconds where NumericDate requires seconds.

Frequently asked questions

Is it safe to paste a JWT here?
Decoding happens entirely in your browser and nothing is transmitted. Even so, treat production tokens as credentials and prefer expired or test tokens where possible.
Why can anyone read my JWT payload?
A JWT payload is Base64URL encoded, not encrypted. Never put secrets in it. The signature only proves the token has not been tampered with.
What does the exp claim mean?
It is the expiry time as a Unix timestamp in seconds. After that moment a correctly implemented server should reject the token.

Looking for something else? Browse all developer tools or see every tool.