Privacy guarantee: This tool runs entirely in your browser. No network requests are made. Your token data stays on your device.

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and information exchange in web APIs. The token is digitally signed, so you can verify its integrity — but by default the payload is only Base64-encoded, not encrypted.

A JWT consists of three parts separated by dots: Header (algorithm and token type), Payload (claims/data), and Signature (used to verify the token hasn't been tampered with).

JWT Standard Claims

  • iss (Issuer) — Who created and signed the token
  • sub (Subject) — Who the token is about (usually user ID)
  • aud (Audience) — Who the token is intended for
  • exp (Expiration Time) — When the token expires (Unix timestamp)
  • iat (Issued At) — When the token was issued
  • nbf (Not Before) — The token isn't valid before this time
  • jti (JWT ID) — Unique identifier for the token

JWT Security Tips

  • Never store sensitive data in JWT payloads — the payload is only Base64-encoded, not encrypted. Anyone can decode it.
  • Always verify the signature server-side — a decoded JWT doesn't mean it's valid. Always check the signature against your secret key.
  • Keep expiry times short — use refresh tokens for long sessions. Short-lived access tokens (15-60 min) limit exposure.
  • Avoid the "none" algorithm — some vulnerable implementations accept unsigned tokens. Always enforce a specific algorithm.
  • Use HTTPS only — transmit JWTs over encrypted connections to prevent interception.

Frequently Asked Questions about JWT

Is it safe to decode a JWT token in the browser?

Yes, decoding a JWT is always safe because the header and payload are only Base64URL-encoded, not encrypted. Anyone who has the token can read its contents — that is by design. This tool decodes your JWT entirely in your browser; your token is never sent to any server. This is also why you should never store passwords, private keys, or sensitive secrets in a JWT payload.

Can I verify a JWT signature without the secret key?

No. JWT signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RS256, ES256). You can always decode the header and payload without a key, but you cannot verify the token has not been tampered with. Signature verification must happen server-side. This tool shows you the decoded token contents for inspection, not signature validity.

Why is my JWT token expiring unexpectedly?

JWT tokens contain an exp claim — a Unix timestamp for when the token expires. If the current time exceeds this value, the token is rejected. This is by design for security. Check the exp value here to understand when your token expires. If tokens expire too quickly, check for clock skew between your server and client — even a few minutes difference causes issues. Use NTP to keep server clocks synchronized.

What algorithm should I use for signing JWT tokens?

For most applications, RS256 (RSA + SHA-256) is recommended because it uses asymmetric keys — you sign with a private key and verify with a public key, so you can share the public key safely. HS256 (HMAC + SHA-256) is simpler but requires sharing the secret key with every service that verifies tokens. Never use the "none" algorithm — some vulnerable implementations accept unsigned tokens, which is a critical security flaw.

Related Developer Tools