Skip to content

JWT Decoder

Pure frontend · decode only, no verification: paste a JWT and it splits the three segments and formats them instantly. Nothing leaves your browser — no network call, nothing recorded, and it will not verify the signature for you.

How to use

Paste a JWT (form xxxxx.yyyyy.zzzzz, three segments joined by two dots) below and click Decode. The tool shows the formatted JSON of header and payload, and turns time fields like exp / iat / nbf into readable dates.

What a JWT actually is

A JSON Web Token is a token format that carries claims as JSON and adds a signature; it is widely used for sessions, API auth, and single sign-on. It looks like this:

header.payload.signature

Three segments joined by dots:

  • header: metadata, typically { "alg": "HS256", "typ": "JWT" }, stating the signing algorithm and type.
  • payload: the real business claims, such as user id, role, and expiry.
  • signature: a signature over header.payload computed with a key, proving the first two were not tampered with.

The key point: the first two segments are only base64url-encoded, not encrypted. Anyone holding the token can decode and read them; only the signature step needs a key.

Common fields at a glance

Field Meaning Notes
iss issuer who issued the token
sub subject who the token represents (user id)
aud audience which service the token is for
exp expiry Unix seconds; invalid after
iat issued at Unix seconds; when issued
nbf not before Unix seconds; invalid before
jti unique id used for replay prevention

These are the standard registered claims; real systems also stuff custom fields (like role, tenant) into the payload. After decoding, match them against this table and the token's story becomes clear.

Decode is not verify — remember this

This is the most misused part of JWT, called out separately:

  • Decoding is public: base64url decoding costs no key; it lays the content open for inspection and reading.
  • Verification is trust: signature verification needs the key and confirms "content unchanged, truly from the issuer". That step only happens server-side where the key lives.
  • Therefore: even if the payload this tool decodes looks perfectly fine, it is not a trust basis. An attacker edits the payload and re-encodes it; it still "decodes legitimately". Trust always rests on server-side verification.

Real security traps

alg=none attack: some libraries accept alg set to none, effectively dropping the signature. An attacker flips alg to none, deletes the signature, and edits the payload freely; poorly configured servers accept it. Robust implementations must explicitly reject none and pin the expected algorithm rather than trusting the token's self-described alg.

Algorithm confusion (RS256 vs HS256): RS256 uses asymmetric keys (public key verifies), HS256 uses symmetric (same key signs and verifies). If a server expects RS256 but allows HS256, an attacker can use the public key as the HMAC secret to forge signatures. Pin the algorithm; never let the token dictate it.

exp is Unix seconds, not milliseconds: plenty of people put a millisecond timestamp into exp, making the token expire instantly or never. If decoded expiry looks absurd (1970 or centuries away), suspect a unit mistake first.

Do not put secrets in the payload: because the payload is encoded, not encrypted, putting a user's email or role there is fine (the receiver should see it), but never put passwords, keys, or ID numbers — anyone holding the token can read them.

When to use this tool

  • While integrating an API, quickly see what claims the backend actually issued and when they expire.
  • Debugging "why am I still 401 after login": decode first and check whether exp already passed or aud is wrong.
  • Auditing a request in logs by its carried sub / jti for traceback.

It helps you read the token, but always leave the "is it trustworthy" judgment to server-side verification.

A decoding example

Take a token of realistic shape (signature truncated, structure only):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcwMDAwMDAwMH0.SflKx...

Decoded:

  • Header: { "alg": "HS256", "typ": "JWT" } — symmetric signing.
  • Payload: { "sub": "user-123", "role": "admin", "exp": 1700000000 } — once exp is turned into a readable time, you instantly see whether this token has expired.
  • Signature: an unreadable blob the tool neither parses nor verifies.

That "decode first, check exp and role" move is exactly the most frequent way you locate auth problems.

Where JWT sits in the ops architecture

  • API gateway: the gateway verifies the JWT signature and decides whether to pass, injecting sub / role into downstream headers. The decoder helps you confirm what claims the gateway actually saw.
  • Inter-service calls: service A calls B and forwards the JWT; B verifies and extracts claims itself, avoiding a central session lookup every time.
  • SSO: log in once, get a JWT, share it across systems, fewer re-logins.
  • Mobile / SPA: the frontend stores the token locally (watch where, and guard against XSS) and sends it on each request.
Scheme State Pros Cons
Session cookie Stateful server Revoke anytime, changes take effect immediately Needs shared session store, scaling cost
Opaque token Server lookup Controllable, revocable A lookup every time, higher latency
JWT Stateless Self-contained, no lookup, easy scaling Hard to revoke instantly, payload not encrypted

Pick by scenario: if you need strong revocation (e.g. emergency kick on risk control), avoid pure JWT; if you need horizontal scaling with self-contained claims across services, JWT fits. Many systems compromise: short-lived JWT plus a refresh token.

How the server verifies (what this tool does not do)

Decoding only lays the content open; verification closes the trust loop. For HS256, the server HMAC-SHA256s header.payload with its key and compares the result to the token's signature — match means trust. RS256 signs with a private key and verifies with the public one. This step must happen server-side, with the key the server holds; because it needs the key, a pure frontend browser tool can never do it, which is exactly why it only decodes.

Reminder: when verifying, pin the algorithm (see the alg=none and algorithm-confusion traps above); do not trust the token's self-described alg.

How refresh tokens fit in

A JWT usually carries a short exp (minutes to a few hours) to shrink the abuse window if leaked. When it expires, a refresh token swaps for a new access token. Refresh tokens are stored separately, revocable, and longer-lived. Debugging "keep getting logged out" starts with decoding the access token to see whether exp is too short or the refresh chain is broken; this tool always looks at the access token itself.

If you suspect a token is malformed, decoding it here is the fastest first step before you dig into gateway logs — you will usually see the problem in the claims within seconds.