JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It consists of three parts: Header, Payload, and Signature, each Base64URL-encoded and joined by dots (.). JWTs are widely used for user authentication, information exchange, and single sign-on (SSO).
• Header: Contains the token type (typ) and signing algorithm (alg), e.g., {"alg":"HS256","typ":"JWT"}
• Payload: Contains claims such as user ID (sub), issuer (iss), expiration time (exp), issued-at time (iat), and more
• Signature: Cryptographically signs Base64(Header) + "." + Base64(Payload) using the algorithm and secret key specified in the Header
• iss (Issuer): Identifies the principal that issued the JWT
• sub (Subject): Identifies the principal that is the subject of the JWT
• aud (Audience): Identifies the recipients that the JWT is intended for
• exp (Expiration Time): The time after which the JWT must not be accepted
• iat (Issued At): The time at which the JWT was issued
• nbf (Not Before): The time before which the JWT must not be accepted
• jti (JWT ID): A unique identifier for the JWT to prevent replay attacks
This JWT decoder is simple yet powerful. Here is the complete guide:
Paste your token: Paste the JWT token string into the input box. A standard JWT consists of three Base64URL-encoded strings separated by two dots, for example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMe.... The tool supports tokens signed with common algorithms such as HS256, RS256, and ES256.
Decode with one click: Click the "Decode Token" button and the tool automatically splits the JWT into Header, Payload, and Signature. The Header and Payload are Base64URL-decoded and displayed as formatted JSON so you can inspect every field easily. The Signature is shown as-is with a note that client-side verification is not possible.
Inspect claims: After decoding, all claims are displayed in a card grid below the Payload. For time-related claims (exp, iat, nbf), the tool automatically converts Unix timestamps into human-readable local date-time and shows relative time (e.g., "expires in 2 hours"). If the token has expired, a red "Expired" badge is displayed prominently.
Copy parts: Each section has a "Copy" button that copies the raw Base64URL-encoded string to your clipboard, handy for use in other debugging tools.
The JWT decoder is widely used in web development and API debugging. Here are typical scenarios:
API debugging: When developing RESTful APIs, front-end and back-end typically use JWT for authentication. When an endpoint returns a 401 Unauthorized error, developers can quickly parse the Authorization header token to check whether it has expired, whether the audience is correct, or whether the claims contain the required permissions. This saves a lot of time compared to manually splitting and Base64-decoding.
Single Sign-On (SSO) troubleshooting: Enterprise applications often use OAuth2.0 / OpenID Connect for SSO. When users report "getting logged out quickly" or "unable to log in to some systems," operations staff can obtain the user's ID Token or Access Token and use this tool to parse the exp (expiration), iss (issuer), and sub (user ID) to quickly determine whether the issue is token expiration, issuer mismatch, or user ID mapping errors.
Microservices call chain tracing: In microservice architectures, services pass user identity and permission context through JWTs. When a downstream service reports insufficient permissions, developers can parse the JWT forwarded by the upstream service and check whether the scope or roles claims in the Payload are complete, pinpointing whether the issue is in token generation or transmission.
Third-party SDK integration: When integrating authentication services like Firebase Auth, Auth0, or AWS Cognito, the tokens returned are JWTs. Developers can use this tool to parse these tokens and verify that custom claims (such as user roles and subscription tiers) match expectations, helping to quickly locate integration configuration issues.
Base64URL vs Base64: JWT uses Base64URL encoding, not standard Base64. Base64URL replaces + with - and / with _, and removes the trailing = padding. This is because JWTs frequently appear in URLs where + and / have special meanings. This tool correctly handles Base64URL decoding during parsing.
JWT security: Although a JWT's signature prevents tampering, it is not encrypted — anyone can decode the Header and Payload to see their contents. Therefore, never store passwords, secret keys, or other sensitive information in the Payload. If you need to protect the Payload content, use JWE (JSON Web Encryption) to encrypt the JWT, or transmit the JWT over HTTPS.
JWT vs Session: Traditional session-based authentication stores user state on the server and associates it with a session ID in a cookie. JWT is stateless — all necessary information is inside the token itself, so the server does not need to store sessions. This makes JWT especially suitable for distributed systems and microservices, but it also brings the drawbacks that tokens cannot be revoked ahead of time (unless a blacklist is used) and that the Payload is relatively large. Choosing between sessions and JWTs depends on your specific architectural needs.
Refresh token mechanism: To mitigate security risks from long-lived access tokens, the dual-token strategy is commonly used: the access token has a short lifetime (e.g., 15 minutes), while the refresh token has a longer lifetime (e.g., 7 days). When the access token expires, the client uses the refresh token to request a new access token from the authentication server. This tool helps you parse both types of tokens and confirm whether their respective expiration times and scopes are configured correctly.
JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. It consists of three parts: Header, Payload, and Signature, each Base64URL-encoded and joined by dots. JWTs are commonly used for authentication, information exchange, and single sign-on (SSO).
No. This tool runs entirely in your browser. All parsing is done locally on your device. Your token data never leaves your browser or gets uploaded to any server. You can safely paste tokens here for debugging.
This tool parses and displays the structure of the JWT's Header, Payload, and Signature, and checks whether the Base64URL encoding is valid. However, signature verification requires the server-side secret key. A client-side tool cannot verify the signature cryptographically. For signature verification, use the corresponding secret key on your server.
If the exp (expiration time) claim shows the token has expired, you need to request a new token from the authentication server, usually by presenting a refresh token. In development environments, you can also generate a new JWT for testing purposes.
No. The JWT Payload uses Base64URL encoding, not encryption. Anyone can decode and read its contents. Never store passwords, secret keys, or other sensitive information in the Payload. For encryption, use JWE (JSON Web Encryption).
A standard JWT must consist of exactly three parts separated by two dots. If the token is missing dots or contains illegal characters, the tool will report a format error. Make sure you have pasted the complete JWT string (including all three parts) with no extra spaces or line breaks.
This tool can parse any standard JWT-format token, including those signed with HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, and ES512. The tool only decodes and displays the structure; it does not verify the signature, so all algorithms are supported.
JWT exp and other time claims use Unix timestamps (seconds since 1970-01-01 UTC). This tool automatically converts them to your local timezone. If the displayed time doesn't match your expectations, check that your timezone settings are correct.