JWT Decoder
Paste a JSON Web Token to inspect its header, payload, and claims — instantly, privately, in your browser.
This tool only decodes the token — it does not verify the signature. Decoding a JWT does not validate it; always verify signatures server-side using the issuer's secret or public key.
Private by design
Tokens are decoded locally in your browser. Nothing is uploaded, logged, or stored on a server.
Instant decoding
Header and payload are decoded as you type, with claim meanings and expiration shown inline.
Claim explanations
Standard JWT claims like iss, sub, exp, and iat are explained next to their values.
What is a JSON Web Token?
A JSON Web Token (JWT, pronounced "jot") is a compact, self-contained way to transmit verified information between two parties. JWTs are the de facto standard for authentication tokens on the web — OAuth 2.0 access tokens, OpenID Connect ID tokens, and session cookies for single-page apps are all commonly issued as JWTs.
Every JWT consists of three base64url-encoded parts joined by dots: the header, which describes the signing algorithm; the payload, which contains the claims (the actual data); and the signature, which is generated from the header and payload using a secret or private key. The signature is what makes the token trustworthy — anyone can decode a JWT, but only the issuer can produce a valid signature.
Decoding vs. verifying a JWT
This tool decodes a JWT, which means it reveals the contents of the header and payload. Decoding is safe and useful for debugging — for example checking what permissions an access token carries, when it expires, or which user it represents.
Verification is different: it cryptographically confirms the token was issued by a trusted party and has not been modified. Verification requires the issuer's secret (for HS256) or public key (for RS256 / ES256) and must always happen server-side. Never grant access or trust a claim based on decoding alone.
Common use cases for a JWT decoder
- Debugging OAuth and OpenID Connect flows with providers like Google, Auth0, Okta, Microsoft, and Supabase
- Checking the
expclaim to confirm a token is not expired - Inspecting custom claims, roles, and scopes embedded in an access token
- Verifying that the
audandissclaims match what your application expects - Reading the
kid(key ID) in the header to find which public key was used to sign the token
Frequently asked questions
›What is a JWT (JSON Web Token)?
A JSON Web Token, or JWT, is a compact, URL-safe way to transmit information between two parties as a JSON object. It is most commonly used for authentication and authorization in web and mobile applications. A JWT has three parts separated by dots: a header describing the signing algorithm, a payload containing claims (data), and a signature used to verify the token has not been tampered with.
›How does this JWT decoder work?
Paste any JWT into the input field and this tool instantly splits it into its three parts, base64url-decodes the header and payload, and renders the JSON for inspection. The signature is shown as-is — decoding a JWT does not verify its signature, which must be done server-side using the issuer's secret key or public key.
›Is decoding a JWT the same as verifying it?
No. Decoding simply reveals what is inside the token. Verification cryptographically checks the signature to confirm that the token was issued by a trusted party and has not been modified. You should never trust a JWT's claims based on decoding alone — always verify signatures on the server before granting access or trusting any claim.
›Is my JWT sent to any server?
No. This decoder runs entirely in your browser using JavaScript's built-in atob and JSON.parse functions. Your token, including any sensitive claims, is never uploaded, logged, or stored. You can safely paste production tokens, access tokens, or ID tokens without worrying about exposure.
›What are common JWT claims like iss, sub, exp, and iat?
These are standard registered claims defined in RFC 7519. iss identifies the issuer (who created the token), sub identifies the subject (usually the user ID), aud identifies the intended audience, exp is the expiration time as a Unix timestamp, nbf is the 'not before' time, iat is the time the token was issued, and jti is a unique token identifier. This decoder shows the human-readable meaning of each claim next to its value.
›How do I tell if a JWT is expired?
Check the exp claim, which is a Unix timestamp in seconds. If the value is less than the current time, the token has expired. This decoder automatically converts exp to a readable date and shows an 'Expired' or 'Valid' badge based on the current time. Note that some systems also enforce nbf (not before) to delay when a token becomes valid.
›What are the different JWT signing algorithms?
The most common algorithms are HS256 (HMAC with SHA-256, using a shared secret), RS256 (RSA with SHA-256, using a public/private key pair), and ES256 (ECDSA with SHA-256, also using a key pair). The algorithm is listed in the alg field of the header. A value of 'none' means the token is unsigned and should never be trusted in production.
›Why does my JWT contain three parts separated by dots?
The three-part structure — header.payload.signature — is the JWS Compact Serialization format defined in RFC 7515. Each part is base64url-encoded so the token is safe to transmit in HTTP headers, URLs, and cookies. The header and payload are JSON objects you can decode; the signature is binary data that must be cryptographically verified, not decoded.
›Can I decode an ID token from Google, Auth0, Okta, or Supabase?
Yes. ID tokens issued by OAuth and OpenID Connect providers like Google, Auth0, Okta, Microsoft, Cognito, and Supabase are standard JWTs and will decode correctly with this tool. You will see standard claims like iss, aud, exp, and sub, along with provider-specific claims such as email, name, picture, and custom roles.
More free developer tools
Part of our growing tool belt — all client-side, all free.