Stax
Tools

JWT Decoder

Decode JWT tokens and inspect header, payload, and expiry.

How JWT works

A JSON Web Token has three Base64url-encoded sections separated by dots. The header specifies the signing algorithm (e.g., HS256, RS256). The payload contains claims — key-value pairs like user ID, roles, and expiry. The signature is created by signing the header and payload with a secret or private key.

Anyone can decode the header and payload without a key — they're just Base64url encoding, not encryption. Only the signature requires the key. This means sensitive data should never go in the payload unless the entire token is encrypted (JWE).

Common debugging uses

  • Check if a token is expired (exp claim)
  • Confirm which user or session a token belongs to (sub claim)
  • Inspect role or permission claims your API is reading
  • Debug authentication issues in development
  • Validate token structure before implementation

JWT security tips

  • Don't store sensitive data in the payload— it's not encrypted, just encoded.
  • Set short expiry times — 15 minutes to 1 hour for access tokens, longer for refresh tokens.
  • Use RS256 over HS256 in multi-service architectures — each service can verify without sharing the secret.
  • Validate the signature server-side — never trust a token the client modifies.

JWT vs session tokens — when to use each

JWTs are stateless — the server does not need to look up a session in a database to validate the token. This makes them ideal for microservices and APIs where multiple services need to authenticate the same user without sharing a session store. The downside is that JWTs cannot be immediately revoked: once issued, they are valid until they expire. For logout-on-demand functionality, you need a token revocation list or very short expiry times combined with refresh tokens.

Traditional session cookies are stored server-side: easy to revoke, but require a shared session store (Redis, database) that all services can access. Choose JWTs for stateless APIs and microservices; choose sessions for monolithic applications where immediate logout is a requirement.

Frequently asked questions

What is a JWT?
JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information JSON object. It consists of three parts separated by dots: a Header (algorithm), a Payload (claims), and a Signature. JWTs are commonly used for authentication and API authorization.
Is it safe to paste my JWT here?
Yes. This tool runs entirely in your browser — no data is sent to any server. That said, treat JWTs like passwords: avoid pasting production tokens from sensitive systems into public tools general best practice. Use test tokens for debugging.
Can this verify the JWT signature?
No. Signature verification requires the secret key (for HMAC) or the public key (for RSA/ECDSA). Since this is a client-side tool, the secret is never available here. Decoding the payload is always possible without the key — which is why sensitive data should never be stored unencrypted in a JWT payload.
What are common JWT claims?
Standard claims include: sub (subject/user ID), iss (issuer), aud (audience), exp (expiry timestamp), iat (issued at), nbf (not before). Custom claims are anything else your application adds, like roles, permissions, or user metadata.
Why is my JWT showing ?
The exp claim is a Unix timestamp. If the current time is past that timestamp, the token is expired. Your server should also reject it. You need to refresh or re-authenticate to get a new token.

Related tools