JWT Decoder

Paste any JSON Web Token to instantly decode its header, payload and claims. 100% client-side - your token never leaves your browser.

Token Input

Waiting for a token

Paste a JWT above or click Sample to decode an example token instantly.

How to use

  1. Paste your JWT into the input area.
  2. The decoder splits it into header, payload, and signature instantly.
  3. Hover over claim names like exp or iat to see human-readable timestamps.
  4. Spot the algorithm (alg) in the header to know how the signature should be verified.
  5. Copy any section as JSON for use in your own debugging.

Frequently asked questions

Does this verify the JWT signature?

No. Signature verification requires the issuer's secret or public key, which should never be pasted into a third-party tool. The decoder only reads and pretty-prints the three Base64 segments.

Is the token uploaded to a server?

No. All decoding happens locally in your browser. JWTs frequently contain sensitive claims, so keeping the data on-device is a deliberate choice.

Why is my JWT considered invalid?

A JWT must have exactly three Base64URL-encoded segments separated by dots. Whitespace, accidental newlines, or missing parts will trigger the invalid-format warning.

What do exp and iat mean?

exp is the expiration time and iat is issued-at, both as Unix timestamps in seconds. The decoder converts them to your local time automatically.

Three parts, two of them readable by anyone

A JSON Web Token is header.payload.signature: three Base64url sections joined by dots. The header names the signing algorithm, the payload carries the claims, and only the signature involves a secret. The decisive fact most newcomers miss: the first two parts are merely encoded, not encrypted. Anyone holding a JWT can read every claim inside it without any key. That is why tokens must travel over HTTPS only and why no secret... passwords, personal data, internal IDs you would not publish... belongs in a JWT payload.

Decoding is not verifying

This tool decodes, which answers "what does this token claim?" Verification answers a different question: "was this token really issued by the expected party and left unmodified?" That requires checking the signature against the issuer's secret or public key, validating the algorithm (rejecting the notorious alg: none), and checking temporal claims. A backend that trusts decoded-but-unverified claims is trivially forgeable.

Reading the standard claims

  • exp and iat are Unix timestamps (seconds since 1970). An exp of 1781234567 is a date in 2026; the decoder translates these for you.
  • iss (issuer) and aud (audience) say who minted the token and who should accept it; mismatches indicate a token used outside its intended service.
  • sub is the user or entity the token represents.
  • Short expirations (15-60 minutes) paired with refresh tokens are standard practice, because a stolen JWT works until it expires... there is no built-in revocation.

Custom claims: reading what applications add

Beyond the registered claims, real tokens carry application-specific payloads... roles, permissions, tenant_id, feature flags, namespaced URLs as claim keys... and decoding them documents an API's authorisation model better than most of its documentation. Inspecting your own product's tokens this way is a worthwhile audit: teams discover internal database IDs, email addresses and occasionally feature roadmaps (those flag names) shipping inside every token to anyone who looks. The design rule the audit enforces: claims are public statements, so a token should carry references and entitlements, never data you would not print on the user's screen.

Advertisement