Gera Tools

JWT Decoder & Structure Verifier

Decode a JWT and inspect its header, payload, and expiry locally

Paste any JWT to decode the header and payload with base64url, validate the JSON structure, check the exp and nbf claims against the current time, and flag security smells like alg none and missing iss or aud. The token never leaves your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Does this verify the JWT signature?

No. Verifying a signature requires the secret or public key, which should never be pasted into a web tool. This tool decodes the structure and checks claims, but a green result is not proof the signature is valid.

A JSON Web Token (JWT) is a compact, URL-safe token made of three base64url-encoded segments — header, payload, and signature — separated by dots. This tool decodes the first two segments in your browser, formats them as readable JSON, checks time-based claims, and surfaces common security issues. Because tokens frequently carry session and identity data, nothing is ever sent to a server.

How the decoder works

A JWT looks like header.payload.signature. The tool:

  1. Splits the token on . and confirms there are three segments.
  2. Base64url-decodes the header and payload (converting -/_ back to +// and restoring padding), then JSON.parses each.
  3. Reads time claims: exp (expiry) and nbf (not before), both Unix seconds, and compares them to the current time.
  4. Runs security heuristics: alg: none (unsigned), suspiciously short tokens, and missing iss or aud claims.

The signature segment is shown verbatim but never validated, because real verification needs the signing key — which should never be pasted into any web page.

What the structure check looks at

Beyond just decoding the JSON, the verifier checks whether the token is structurally sound for production use:

CheckWhat it flags
alg: noneToken is unsigned — a critical vulnerability if accepted
Missing aud claimAudience not set — token could be replayed across services
Missing iss claimIssuer not identified — harder to enforce token origin
Token expiredCurrent time is past exp — should be rejected
Token not yet validCurrent time is before nbf — should be rejected
Very long expiryAn exp set months or years out is a security smell

None of these checks validate the signature — only that the claims are present and the timestamps are in range. Always perform cryptographic signature verification on your server before trusting any claim.

Understanding alg: none

The none algorithm means the token has no signature. RFC 7519 defines it as a valid algorithm, but accepting it in production is a critical security flaw: an attacker can fabricate any payload, set alg: none, and submit it without a signature. Any JWT library that accepts none without being explicitly configured to do so is misconfigured. The tool flags it because it appears in real tokens encountered during testing and debugging, and every developer who sees it should understand why it must be blocked.

Tips and common mistakes

  • A decoded payload is readable by anyone who has the token. Never store passwords, PII, or secrets in JWT claims — the payload is encoding, not encryption.
  • Always verify the signature server-side using an explicit algorithm allow-list. Reject none; also reject any algorithm you did not configure (for example, reject RS256 if your system only issues HS256).
  • An expired result here may still be accepted on a server with clock-skew tolerance; the exp check here is informational, not definitive.
  • Short-lived access tokens combined with refresh tokens are safer than long expiries. If you see an exp set years in the future, that is worth flagging to the issuing team.
  • Missing aud is the source of a class of bugs where a token minted for one internal service is replayed against another. Set aud and verify it.