JWT Decoder

This token analyzer makes decoding a JWT a two-step job:

1. Paste your token into the input box (or click Load Sample to try one). The decoder splits the token on its dots and reads each part.
2. Read the output: the decoded header shows the signing algorithm, the payload shows every claim, and the standard claims panel flags expiration (exp) so you can tell at a glance whether a token is still valid.

It is a pure decoder: it reveals what is inside a token but does not verify the signature, since that needs the issuer's secret or public key. If you are debugging an OIDC login flow against Keycloak, the access and ID tokens you see here come straight from your identity provider, and our Keycloak documentation covers how those claims are issued and mapped.

A JSON Web Token (JWT) is a compact, URL-safe way of representing claims to be transferred between two parties. JWTs are commonly used for:

• Authentication: After login, a JWT is issued and sent with each request
• Authorization: JWTs contain claims about what the user can access
• Information Exchange: Securely transmitting data between parties

JWTs are self-contained, meaning all necessary information is in the token itself.

A JWT consists of three parts separated by dots (.):

• Header: Contains the token type and signing algorithm (e.g., RS256, HS256)
• Payload: Contains the claims - statements about the user and metadata
• Signature: Verifies the token hasn't been tampered with

Example: eyJhbGc....eyJzdWI....SflKxw...

Standard JWT claims (registered claims) include:

• iss (Issuer): Who issued the token
• sub (Subject): Who the token represents
• aud (Audience): Intended recipient
• exp (Expiration): When the token expires
• iat (Issued At): When the token was issued
• nbf (Not Before): Token not valid before this time
• jti (JWT ID): Unique token identifier

• Always verify signatures: Don't trust decoded data without verification
• Check expiration: Always validate exp claim before accepting tokens
• Use HTTPS: JWTs should only be transmitted over secure connections
• Keep secrets secure: Never expose signing keys in client-side code
• Use appropriate algorithms: Prefer RS256 over HS256 for public clients
• Set short expiration: Access tokens should be short-lived (minutes, not days)

Is it safe to decode a JWT in this tool?

Yes. The decoding runs entirely in your browser with JavaScript, so the token is never uploaded, stored, or logged anywhere. That said, treat any real access token like a password: a decoded payload is human-readable, so avoid pasting production tokens into tools you do not trust.

Does this JWT decoder verify the signature?

No. This is a decoder and token analyzer: it shows the header, payload, claims, and signing algorithm, but verifying the signature requires the issuer's secret (HS256) or public key (RS256). Decoding tells you what a token claims; verification tells you whether to trust it, and you should always verify on the server.

How do I tell if a JWT is expired?

Look at the exp claim in the decoded payload. It is a Unix timestamp for when the token stops being valid, and this analyzer surfaces it in the standard claims panel so you can see expiry without converting epoch time by hand. A missing exp means the token has no built-in expiry, which is usually a red flag.

Why is my Keycloak access token so large?

Keycloak tokens carry realm and client roles, group memberships, and any custom protocol mappers you add, so they grow quickly. If a token is too big for your needs you can trim the claims via client scopes and mappers. Managed setups handle key rotation and sane defaults for you: see Skycloak managed Keycloak hosting.