Decode and inspect JWT tokens online without verification. Instantly view the header, payload claims, and expiration date — all processed locally in your browser.
| Claim | Key | Value |
|---|
JWT Decoder is a free online tool that lets you decode JSON Web Tokens (JWTs) without requiring a secret key or verification step. A JWT consists of three parts separated by dots: a Base64url-encoded header, a Base64url-encoded payload, and a signature. This tool decodes the first two parts and displays all claims in a structured table with human-readable timestamps and expiry calculations.
Use the JWT Decoder whenever you need to quickly inspect the contents of a JWT during development or debugging. It is especially useful when troubleshooting authentication and authorization flows, verifying that tokens contain the correct claims before sending them to an API, or checking whether a token has expired.
Developers commonly use JWT Decoder to inspect access tokens and refresh tokens issued by OAuth 2.0 providers, debug authentication middleware by verifying token payloads, check token expiration times to understand session lifetimes, examine custom claims embedded in tokens for role-based access control, and validate that token headers specify the expected signing algorithm.
Essential terms and definitions related to JWT Decoder.
A compact, URL-safe token format defined by RFC 7519 for securely transmitting information between parties as a JSON object. A JWT consists of three Base64URL-encoded parts separated by dots: header (algorithm and type), payload (claims), and signature (verification data). JWTs are widely used for stateless authentication in REST APIs.
The first segment of a JWT token containing metadata about the token itself: the signing algorithm (alg) such as HS256 or RS256, and the token type (typ), which is typically "JWT". The header is Base64URL-encoded and determines how the signature is computed and verified.
The second segment of a JWT containing the actual data as key-value pairs called "claims." Standard claims include: iss (issuer), sub (subject), exp (expiration time), iat (issued at), and aud (audience). Custom claims can carry any application-specific data such as user ID, roles, or permissions.
The third segment of a JWT that ensures the token has not been tampered with. It is created by signing the encoded header and payload with a secret key (HMAC) or a private key (RSA/ECDSA). The recipient verifies the signature using the shared secret or the corresponding public key. This tool does not verify signatures — it only decodes and displays content.
No. This tool decodes and displays the JWT header and payload without verifying the signature. It is a debugging and inspection tool, not a security validation tool. Never trust a JWT solely based on its decoded content without signature verification.
Yes. The decoder displays the token contents regardless of expiration status. It will show the exp (expiration) claim in the payload so you can see when the token expired, but it does not prevent you from viewing expired tokens.
The decoder shows whatever algorithm is specified in the JWT header (alg field), such as HS256, RS256, ES256, or none. It displays this information but does not perform any cryptographic operations.
Yes, because all decoding happens locally in your browser. No data is sent to any server. However, you should still be cautious about sharing decoded token contents, as JWTs often contain sensitive user claims and permissions.
Common errors developers encounter and how to resolve them.
InvalidTokenError: Invalid JWT structure — 3 segments expected A valid JWT token consists of three segments in the header.payload.signature format, separated by dots (.). If you get a "jwt malformed" or segment count error, make sure the token was copied completely — especially with long tokens, characters may be truncated from the beginning or end during copy-paste. Remember to remove the Bearer prefix ("Bearer ") since many HTTP Authorization headers prepend it to the token. Paste it into this tool to quickly validate the token structure.
Invalid Signature: HS256 vs RS256 algorithm mismatch If JWT signature verification is failing, check the alg (algorithm) field in the header. HS256 (HMAC-SHA256) uses a symmetric secret key, while RS256 (RSA-SHA256) uses an asymmetric public/private key pair. Verifying with the wrong key type will always produce an "invalid signature" error. Important security note: never accept alg:"none" — this is a known JWT attack vector that bypasses signature verification (CVE-2015-9235).
Payload parsing error: Corrupted JSON during Base64URL decode JWT payloads are encoded with URL-safe Base64 (Base64URL), not standard Base64: + is replaced with -, / with _, and padding (=) is removed. If you try to manually decode the payload without accounting for this difference, atob() will throw an invalid character error or produce corrupted JSON output. Also verify that the payload is valid JSON — some legacy implementations may have non-JSON payloads. This tool automatically handles Base64URL conversion and displays the parsed JSON.
Token expired (exp claim): Timing and clock skew issues The exp (expiration) claim in a JWT is stored as a Unix timestamp. If you get a "Token expired" error, check that the server clock is accurate — clock skew between client and server can cause the token to expire prematurely. As a best practice, allow a 30-60 second clock skew tolerance in JWT verification. Use this tool to decode your token and inspect the exp, iat (issued at), and nbf (not before) claim values.