JWT Decoder

About the JWT Decoder

The JWT Decoder reads the header and payload of a JSON Web Token (JWT) without verifying the signature. JWTs are the standard way to represent claims (authentication, authorization, session state) in modern web applications. They appear in OAuth access tokens, OpenID Connect ID tokens, SAML alternatives, and many API authentication schemes. A JWT is a Base64-encoded string with three parts separated by dots: header.payload.signature.

Decoding a JWT lets you inspect what claims it carries — who issued it, who it is for, when it expires, what permissions it grants. This is invaluable when debugging authentication failures (“Why does this token say expired?”), verifying that your auth server is including the right claims, or understanding what a third-party API expects in its tokens.

Important: this tool decodes the JWT but does not verify the signature. Anyone can create a JWT with any claims and sign it with any key. Decoding shows you what the token claims, not that the claims are true. Never trust a decoded JWT's claims for security decisions without first verifying the signature using the issuer's public key.

How It Works

A JWT has three Base64url-encoded parts separated by dots:

1. Header — a JSON object describing the token type (typ, usually "JWT") and the signing algorithm (alg, like "HS256" or "RS256").
2. Payload — a JSON object containing claims. Standard claims include sub (subject), iss (issuer), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims can be anything.
3. Signature — the cryptographic signature over the header and payload, used to verify that the token has not been tampered with.

The tool splits the JWT on dots, then Base64url-decodes the first two parts. Base64url is a variant of Base64 that uses - instead of + and _ instead of /, and typically omits the = padding. The tool converts Base64url to standard Base64, adds padding, decodes with atob(), interprets the result as UTF-8, and parses it as JSON.

The tool also interprets the standard time-based claims (exp, iat, nbf) which are Unix timestamps in seconds. It converts them to human-readable dates and flags whether the token is expired (exp in the past) or not yet valid (nbf in the future).

Worked Examples

The default token decodes to a header of {"alg":"HS256","typ":"JWT"} and a payload of {"sub":"1234567890","name":"John Doe","iat":1516239022}. The issued-at timestamp 1516239022 corresponds to January 17, 2018. Because there is no exp claim, the token does not have an expiration date (unusual but valid).

For a real OAuth access token from an API, you would see claims like scope (the granted permissions), client_id (which application requested the token), aud (which API the token is for), and exp (when the token expires, typically 1 hour after issuance). Decoding lets you verify that the token has the scopes your application needs before making API calls.

For an OpenID Connect ID token, the payload contains user identity claims like email, name, picture, and email_verified. Decoding the ID token in your browser lets you display the user's name and avatar without making a separate API call to the userinfo endpoint — a common optimization in single-page applications.

When to Use This Tool

• Debugging authentication failures by inspecting token claims (wrong audience, expired, missing scope).
• Verifying that your auth server is including the expected claims in issued tokens.
• Extracting user identity (name, email, avatar) from an OpenID Connect ID token for display.
• Inspecting OAuth access tokens to verify granted scopes before making API calls.
• Understanding the structure of a JWT when integrating with a new API or auth provider.
• Teaching how JWTs work by showing the decoded header and payload.
• Checking token expiration time to proactively refresh tokens before they expire.

Limitations & Disclaimer

This tool decodes the JWT header and payload but does not verify the cryptographic signature — never trust the decoded claims for security decisions without verifying the signature using the issuer's key. The tool does not support encrypted JWTs (JWE, which require a decryption key). Time-based claims are interpreted as Unix timestamps in seconds (the JWT standard); tokens using milliseconds or other formats will show incorrect dates. The tool does not validate claim formats or enforce required claims. Some custom claims may not be JSON-serializable in unusual cases. See our disclaimer for full terms.

Frequently Asked Questions

Last updated: July 21, 2026  ·  Author: HT99 Tools Editorial Team  ·  Reviewed by: HT99 Tools Editorial Team