Is my token sent to a server?

No. The token is split and Base64URL-decoded locally with the browser's built-in atob() and JSON.parse(). It never leaves your device, so it is safe to use with real tokens.

Does this verify the signature?

No. Verifying a JWT signature requires the secret or public key, which is server-side information. This tool decodes and explains only the readable header and payload — exactly what any recipient sees before verifying.

How accurate are the claim descriptions?

The standard registered claims (iss, sub, aud, exp, nbf, iat, jti) follow their RFC 7519 definitions. Any non-standard key is labelled as a custom application claim rather than guessed.

What is the JWT Claims Explainer?

Free JWT claims explainer that decodes a JSON Web Token and explains each standard registered claim (iss, sub, aud, exp, nbf, iat, jti) in plain English, with expired and not-yet-valid warnings. Runs entirely in your browser — your token is never sent anywhere. It runs free in your browser on Gera Tools, with nothing uploaded.

JWT Claims Explainer

Name: JWT Claims Explainer
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

JWT claims explainer

A JSON Web Token is readable but cryptic out of context. The header and payload are only Base64URL-encoded — not encrypted — so anyone who has the token can decode them. But the three-letter claim names (iss, sub, aud, exp, nbf, iat, jti) and Unix timestamps require a reference to make sense.

Paste a token here and the tool decodes the header and payload, then adds a plain-English explanation of every standard registered claim defined in RFC 7519, plus UTC-formatted dates for every timestamp.

The standard registered claims

RFC 7519 defines seven registered claim names that token issuers should use when they need those concepts. Using the standard names means any consumer that knows the spec can interpret them without custom documentation.

Claim	Full name	What it means
`iss`	Issuer	The principal that issued the token — typically a domain or service identifier
`sub`	Subject	The entity the token is about — usually a user ID
`aud`	Audience	The intended recipient(s) — a server should reject tokens not addressed to it
`exp`	Expiration	The time after which the token must not be accepted (Unix seconds)
`nbf`	Not before	The time before which the token is not yet valid (Unix seconds)
`iat`	Issued at	The time the token was issued (Unix seconds)
`jti`	JWT ID	A unique identifier for this token, used to prevent replay

Time claims (exp, nbf, iat) are converted to readable UTC dates. If the current time is past exp, the token is flagged EXPIRED. If the current time is before nbf, it is flagged NOT YET VALID. Custom application claims that do not match any registered name are labelled as such.

Why each claim matters in practice

iss and aud together prevent cross-service token replay. If a token issued by your auth server for service A is presented to service B, and B checks that aud matches its own identifier, it will reject the token even though the signature is valid. Missing aud is a common misconfiguration that makes token theft more dangerous.

exp sets the token lifetime. Short-lived access tokens (minutes to hours) limit the damage from a leaked token. If you paste a token and see an exp set years in the future, that is a signal the issuer is relying on revocation lists rather than natural expiry.

nbf is used less often, but it lets a server issue a token that is only valid starting at a future time — useful for scheduled access grants.

jti enables single-use tokens by letting the server record and reject previously seen IDs. Without it, a valid token can be replayed as many times as an attacker wants within its exp window.

Worked example

A payload of:

{
  "iss": "https://auth.example.com",
  "sub": "user_abc123",
  "aud": "https://api.example.com",
  "iat": 1700000000,
  "exp": 1700003600,
  "jti": "e3b0c44298fc"
}

decodes as: issued by auth.example.com for subject user_abc123, addressed to api.example.com, issued at 2023-11-14 22:13:20 UTC, expiring one hour later at 23:13:20 UTC. If you paste this after the expiry time, the tool flags it EXPIRED.

Everything runs in your browser — the token is never transmitted. The signature is shown but never verified; verifying requires the signing key, which you should never paste into any web tool.