JWT Decoder

JSON Web Tokens (JWTs) are a compact, URL-safe way to represent claims between two parties, widely used for authentication and API authorization. This tool decodes a JWT's header and payload client-side so you can inspect algorithm, issuer, expiry, and custom claims instantly. No token data is ever sent to any server — all decoding happens in your browser.

Tip: Press Ctrl+Enter to run

What this tool does

Paste a JWT and this tool splits it into its three parts — header, payload, and signature — and renders the header and payload as formatted, syntax-highlighted JSON. It also translates any Unix timestamp claims (exp, iat, nbf) into readable dates, and flags if the token has already expired. Decoding is entirely local — your token never leaves your browser. That matters, because JWTs often carry session data, user IDs, and permission scopes that shouldn't be sent to third-party services.

How to use it

  • Paste the full JWT string — it starts with eyJ (Base64url for {") and has two dots in it.
  • The tool decodes as you type. You don't need to click anything.
  • Check the Header panel for the alg field — this tells you what signing algorithm was used (HS256, RS256, etc.).
  • Check the Payload panel for standard claims: sub (subject/user ID), iss (issuer), aud (audience), exp (expiry), iat (issued at).
  • The human-readable dates below the payload panel show exactly when the token was issued and when it expires.
  • Copy the header or payload as raw JSON using the Copy buttons.

Common JWT claims and what they mean

  • sub — Subject: identifies who the token is about, usually a user ID.
  • iss — Issuer: identifies which system issued the token (e.g. https://auth.example.com).
  • aud — Audience: which service(s) this token is intended for. Your API should reject tokens with the wrong audience.
  • exp — Expiration: Unix timestamp after which the token is invalid. Check this first when debugging "token expired" errors.
  • iat — Issued At: when the token was minted. Useful for checking if a token is suspiciously old.
  • nbf — Not Before: the token should not be accepted before this time.

Frequently Asked Questions

Does this tool verify the signature?

No — and that's intentional. Verifying the signature requires the secret key (for HS256) or the public key (for RS256/ES256), which this tool doesn't have. The warning at the bottom of the decode output reminds you of this. Decoding lets you read the claims; verification is what proves the token hasn't been tampered with. Always verify server-side before trusting any claim.

Is it safe to paste a real JWT here?

The tool processes everything locally — nothing is sent to a server. That said, production tokens from live sessions carry real credentials. The safer habit for debugging: use short-lived test tokens, or invalidate/revoke the real token after you're done inspecting it. Don't paste access tokens into any online tool as a routine practice.

What is Base64url and why is it different from regular Base64?

Standard Base64 uses + and /, which are special characters in URLs. Base64url swaps them for - and _ and drops the = padding. This makes JWTs safe to pass as query parameters or HTTP headers without percent-encoding them. If you're decoding a JWT manually, remember to replace - with + and _ with / before passing to a standard base64 decoder.

What does alg: none in the header mean?

It means the token has no signature — the third part is empty. Some early JWT libraries accepted alg: none tokens as valid, which was a critical vulnerability (an attacker could strip the signature and modify the payload). Any modern, correctly implemented JWT library should reject alg: none tokens. If you see this in a real token from your system, that's a security problem worth investigating immediately.

Want the full explanation? Read the guide: Decoding JWTs: What's Actually Inside That Token →