Decode and Inspect JWT Tokens Securely
What It Is. JSON Web Tokens (JWT) are the standard for stateless authentication across web APIs. When debugging authentication flows, inspecting JWT payloads helps verify token contents, check expiration times, and validate claims. This decoder processes tokens entirely client-side - your secrets never leave your browser.
How It Works
A JWT has three Base64URL-encoded segments separated by dots: the header indicates the signing algorithm (HS256, RS256, or ES256), the payload contains registered claims (iss, sub, aud, exp, nbf, iat, jti) plus custom claims, and the signature is a cryptographic hash of the header and payload using the algorithm from the header. The decoder splits the token at each dot, Base64URL-decodes the header and payload, and parses the resulting JSON. The third segment (signature) is displayed as raw bytes since it requires the original signing key to verify.
Worked Example
Input token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Decoded header: {"alg": "HS256", "typ": "JWT"}
Decoded payload: {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
The header shows the token uses HMAC-SHA256 (HS256). The payload contains a subject claim (sub), the user's name, and an issued-at timestamp (iat). The tool converts the iat Unix timestamp to a human-readable date and calculates the time elapsed since issuance.
Common Mistakes
- Trusting unverified JWTs. This decoder shows the decoded header and payload but does not automatically verify the signature. A token can be decoded by anyone - decoding does not imply authenticity. Always verify the signature on your server using the correct secret or public key before trusting the claims.
- Confusing Unix timestamps with human-readable dates. The exp, iat, and nbf claims are Unix timestamps in seconds since epoch, not milliseconds. JavaScript
Date.now()returns milliseconds, so comparingexp * 1000withDate.now()is a common off-by-factor-1000 bug that causes premature or delayed expiration. - Ignoring the "alg": "none" attack. Some JWT libraries accept tokens with
{"alg": "none"}in the header, bypassing signature verification entirely. If your decoder or server accepts unsigned tokens, an attacker can forge arbitrary claims. Always reject tokens with alg=none on the server side.
Frequently Asked Questions
Q:What is a JWT token and why are they used?
JWT (JSON Web Token) is a compact, URL-safe token format used for stateless authentication. The token consists of three Base64URL-encoded parts: header (algorithm info), payload (claims), and signature. JWTs enable scalable authentication without server-side session storage.
Q:How do I decode the signature to verify it?
This decoder shows the parsed header and payload but does not automatically verify signatures. Signature verification requires the original secret key (for HS256/HS384) or public key (for RS256/ES256). The Pro feature gate unlocks server-side verification with custom keys and JWKS endpoint support.
Q:What does the exp claim mean in a JWT?
The exp (expiration) claim is a Unix timestamp indicating when the token becomes invalid. Most JWT libraries automatically reject expired tokens. This tool shows a live countdown so you can see exactly how much time remains before the token expires.
Q:What does the "kid" field in the JWT header mean?
The "kid" (Key ID) field is an optional header parameter that hints at which key was used to sign the token. When a server rotates signing keys, the kid helps the verifier select the correct public key from a JWKS (JSON Web Key Set) endpoint. Without a matching kid, RS256/ES256 tokens cannot be verified.
Q:What is the difference between HS256 and RS256?
HS256 (HMAC with SHA-256) uses a single shared secret for both signing and verification - the same secret must be kept private on both the issuer and verifier. RS256 (RSA with SHA-256) uses a private/public key pair: the issuer signs with a private key and anyone with the public key can verify. RS256 is preferred for server-to-server communication as the signing key never needs to be shared.