JWT Decoder

Encoded

Decoded

{ "alg": "HS256", "typ": "JWT" }

Payload

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

Signing Key

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
---Enter-your-256-bit-key---

Signature Verified!

Note: We do not store any information in our database and all processing is done on the client side.

The JWT Decoder Tool allows you to decode JWTs for simple debugging. You can also create your own JWTs with custom payloads signed with your own secret for testing purposes.

What are JWTs

JSON Web Token is an open industry standard used to share information between two entities.

They contain JSON objects which have the information that needs to be shared. Each JWT is also signed using cryptography to ensure that the client or a malicious party cannot alter the JSON contents.

Structure of a JWT

A JWT contains three distinct parts that work together to create a secure, self-contained token. These parts are separated by dots (.) and each serves a specific purpose in the token's functionality and security. The three parts are:

Header

The header contains metadata about the token. It consists of two parts:

• The signing algorithm that's being used.
• The type of token, which, in this case, is mostly "JWT"

Payload

The payload contains the claims or the JSON object. It is a JSON object that is encoded using Base64Url encoding.

Common JWT Claims:

• iss: The issuer of the token (in this case Google)
• azp and aud: Client IDs issued by Google for your application. This way, Google knows which website is trying to use its sign in service, and the website knows that the JWT was issued specifically for them.
• sub: The end user's Google user ID
• at_hash: The hash of the access token. The OAuth access token is different from the JWT in the sense that it's an opaque token. The access token's purpose is so that the client application can query Google to ask for more information about the signed in user.
• email: The end user's email ID
• email_verified: Whether or not the user has verified their email.
• iat: The time (in milliseconds since epoch) the JWT was created.
• exp: The time (in milliseconds since epoch) the JWT will expire.
• nonce: Can be used by the client application to prevent replay attacks.
• hd: The hosted G Suite domain of the user

Signature

A string that is generated via a cryptographic algorithm that can be used to verify the integrity of the JSON payload.

Common Use Cases for JWT Decoding

Debugging Authentication Issues

When users report issues with login or permissions, decoding the JWT reveals critical claims like exp (expiration), iss (issuer), aud (audience), and scope or roles. This inspection helps identify issues like expired tokens, incorrect issuers, or missing permissions—before they lead to broken workflows.

Inspecting Token Claims

JWTs contain structured claims that reveal user roles or privileges. Developers decode access tokens during runtime to populate UI features (e.g., showing admin-only options) or enforce backend ACLs based on claims such as roles or scope.

Security Considerations ⚠️

Signature Verification

Never rely on decoded data alone. Always verify the signature to ensure the token wasn't forged or tampered with.

Risks of Decoding Unverified Tokens

Decoding without verification can expose you to:

• Injection of false claims
• Expired or replayed tokens
• Forged user roles or escalated privileges

You can find our complete guide on how JWT works and how you can generate JWTs in this blog.