JWT Debugger & Decoder

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs are the most common way to handle authentication and authorization in modern web applications and APIs.

Our JWT Debugger is an essential utility for developers working with these tokens. It allows you to instantly decode and inspect the contents of a JWT, making it easy to debug issues related to token expiration, incorrect claims, or signature algorithms. Because it is a 100% client-side tool, your sensitive tokens are never sent to a server, guaranteeing their privacy.

1. The Header (Metadata)

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 (HS256) or RSA (RS256). For example:

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

This JSON is then Base64URL encoded to form the first part of the JWT.

2. The Payload (Claims)

The payload contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims:

• Registered Claims: These are a set of predefined claims which are not mandatory but recommended. Some common ones include iss (issuer), exp (expiration time), sub (subject), and aud (audience).
• Public Claims: These are claims defined at will by those using JWTs. But to avoid collisions, they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision-resistant namespace.
• Private Claims: These are custom claims created to share information between parties that agree on using them. Examples include user roles, permissions, or internal user IDs.

An example payload might look like this:

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

The payload is also Base64URL encoded to form the second part of the JWT. Our Base64 Encoder/Decoder can help you understand this part of the process.

3. The Signature

To create the signature part, you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

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

The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is. This tool does not and cannot validate the signature, as that requires your secret key.