{ }
中文

JWT Decoder

Paste a JSON Web Token to decode its header and payload. Decoding only — signature verification is not performed.

What is a JSON Web Token?

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe means of representing claims between two parties, defined by RFC 7519. A JWT consists of three Base64URL-encoded segments separated by dots: a header that declares the signing algorithm, a payload that carries the claims, and a signature that protects integrity. The whole token is short enough to live inside a cookie, an Authorization header, or a query string.

JWT decoding is a purely client-side operation: split the string on dots, Base64URL-decode the first two segments, and parse them as JSON. This tool does exactly that — it never contacts a server and never performs signature verification, because verification requires the issuer's secret or public key, which lives only on the server. Treat the decoder as a debugging aid, not as an authentication check.

Standard claims defined by RFC 7519 include iss (issuer), sub (subject), aud (audience), exp (expiration time as a Unix timestamp), nbf (not before), iat (issued at), and jti (token ID). Custom claims may be added by application authors; tokens issued by Auth0, AWS Cognito, Firebase, Supabase, and Keycloak follow this pattern with provider-specific extensions.

Use cases

  • Inspect what an authentication provider is sending in the Authorization header.
  • Verify that the exp (expiration) claim has not passed when a request is being rejected as unauthorized.
  • Read the sub or email claim to confirm which user a token belongs to.
  • Compare two tokens to see why one is being rejected by the API gateway.
  • Confirm the algorithm (alg in the header) before configuring a verifier on the server side.

Best practices

  • Never trust a JWT until the signature has been verified server-side with the issuer's public key.
  • Keep tokens short-lived (minutes, not weeks) and refresh them with a separate refresh token.
  • Do not store sensitive data in the payload — JWT is signed but not encrypted by default.
  • Reject tokens with alg = none on the server; accept only the algorithm you expect.
  • Store JWTs in HttpOnly cookies when possible to mitigate XSS, not in localStorage.

Frequently asked questions

Is the token verified by this tool?
No. Verification requires the issuer's secret or public key, which only the server has. This tool only decodes; do not rely on it for security decisions.
Is the payload encrypted?
No, JWTs are signed (JWS) by default, not encrypted. Anyone holding the token can read the payload. Use JWE if confidentiality is required.
What does the alg field mean?
It declares the signing algorithm — for example HS256 (HMAC-SHA256), RS256 (RSA-SHA256), or ES256 (ECDSA P-256).
Why is the third segment empty for some tokens?
An empty signature indicates an unsigned token (alg = none). This is dangerous and should never be accepted by a production verifier.
How do I know if a token is expired?
Check the exp claim — it is a Unix timestamp in seconds. The decoder shows the parsed expiration date and warns when it is in the past.