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.
A JSON Web Token consists of three Base64URL-encoded parts separated by dots: the header, payload, and signature. The header specifies the signing algorithm (typically HS256 or RS256) and the token type. The payload contains claims — standardized fields like iss (issuer), exp (expiration), sub (subject), and iat (issued at) — plus any custom data your application needs. The signature verifies that the token hasn't been tampered with by hashing the header and payload with a secret key or RSA private key.
| Feature | HS256 (HMAC) | RS256 (RSA) |
|---|---|---|
| Key type | Shared secret | Public/private key pair |
| Verification | Requires the secret | Public key only |
| Performance | Faster | Slower (asymmetric) |
| Best for | Single-service apps | Microservices, OIDC, third-party verification |
Use HS256 when the same service creates and verifies tokens. Use RS256 when multiple services need to verify tokens without sharing a secret — common in OAuth 2.0 and OpenID Connect architectures.
Never store sensitive data like passwords in the JWT payload — it is encoded, not encrypted. Always set expiration times (exp) to limit the damage window if a token is compromised. Validate the alg header on the server side to prevent algorithm confusion attacks. Use HTTPS exclusively — JWTs in transit over HTTP can be intercepted and replayed. Store tokens in HttpOnly cookies instead of localStorage to prevent XSS-based theft. Implement token refresh flows so short-lived access tokens can be renewed without re-authentication.
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.
In-depth articles covering the concepts behind JWT Decoder.
Web Security: Encoding and Hashing Guide
Understand the differences between encoding, hashing, and encryption. Learn when to use Base64, SHA-256, bcrypt, AES, and HTML entity encoding for web security — with code examples and decision flowcharts.
HTTP Status Codes: The Complete Guide for Developers
Every HTTP status code explained with real-world examples. Learn when APIs should return 200 vs 201, why 403 and 401 are different, and how to debug 5xx errors in production.
Why Base64 is Not Encryption
Base64 encoding is often mistaken for encryption. Learn exactly why Base64 provides zero security, see real-world vulnerability examples, and understand what to use instead for passwords, API keys, and sensitive data.