JWT Decoder

A JWT decoder is a tool that converts the readable parts of a JSON Web Token from Base64URL-encoded data into structured JSON. A typical JWT contains three dot-separated sections: a header, a payload and a signature.

The header usually contains token metadata such as the signing algorithm and token type. The payload contains claims such as the issuer, subject, audience, issued-at time and expiration time. A decoder lets you inspect these values without needing the signing secret or private key.

A JWT decoder should not be confused with a JWT signature verifier. Decoding reveals what the token contains; verification checks whether the token was signed correctly with the appropriate cryptographic key.

To decode a JWT token, paste the complete token into the JWT Decoder and select Decode JWT. A standard JWT normally contains three sections separated by periods:

header.payload.signature

The decoder reads the Base64URL-encoded header and payload and displays them as formatted JSON. You can then inspect the token information, algorithm, claims, timestamps and individual JWT sections.

If you have copied a token from an HTTP authorization header, remove the surrounding Bearer prefix if necessary. A decoder can read the JWT itself; the authentication scheme is separate from the token's encoded contents.

A JSON Web Token is commonly represented as three Base64URL-encoded sections separated by periods.

• Header: Contains metadata about the token, commonly including alg for the signing algorithm and typ for the token type.
• Payload: Contains claims and application-specific data carried by the token.
• Signature: Represents the cryptographic signature associated with the encoded header and payload.

The header and payload can normally be decoded without a secret because Base64URL encoding is not encryption. Reading those sections does not establish that the token is authentic.

JWT claims are pieces of information contained in the payload. Common registered claims include iss, sub, aud, exp, nbf, iat and jti.

• iss identifies the issuer of the token.
• sub identifies the subject represented by the token.
• aud identifies the intended audience.
• exp specifies when the token expires.
• nbf specifies the time before which the token should not be accepted.
• iat records when the token was issued.
• jti can provide a unique identifier for the token.

Applications can also include custom claims for roles, permissions, tenant information and other application-specific data.

The exp claim is commonly used to specify the expiration time of a JWT. JWT time claims are normally represented as NumericDate values, which are based on Unix time in seconds.

This decoder interprets supported time claims and presents them in a human-readable date format. The expiration status helps you quickly determine whether a decoded token has passed its stated expiration time.

The nbf claim can also be useful when debugging authentication problems because it indicates a time before which the token should not be accepted.

Decoding and verification are different operations.

Decoding reads the Base64URL-encoded header and payload and converts them into JSON. It does not require a signing secret or public key.

Signature verification uses the appropriate cryptographic algorithm and verification key to determine whether the signature matches the token's encoded header and payload.

A token that decodes successfully is not automatically trustworthy. Authentication and authorization decisions should rely on verification performed by the appropriate application or trusted authentication system.

Yes. You do not need the signing secret or private key to decode the header and payload of a normal JWT. Those sections are encoded using Base64URL rather than encrypted with a secret.

The signing key becomes relevant when verifying the token's signature. Therefore, being able to read a JWT does not mean that you can prove who issued it or that its claims are authentic.

Not every JWT is encrypted. A commonly used signed JWT, also called a JWS, contains a Base64URL-encoded header and payload plus a signature. Base64URL encoding makes the data suitable for compact transmission but does not hide the contents.

If confidential information must be protected cryptographically, an application needs an appropriate encryption mechanism rather than assuming that a signed JWT automatically provides confidentiality.

JWTs are frequently encountered while debugging authentication and API requests. A decoder can help developers inspect whether expected claims are present, identify the signing algorithm listed in the header, and check timestamps such as iat, nbf and exp.

This can be useful when investigating access-token behavior, OAuth or OpenID Connect integrations, API authorization problems, and authentication flows involving identity providers or web applications.

The decoder shows the contents of the token, but it does not replace the verification performed by the application receiving the token.

AabiTech performs the JWT decoding operation in your browser using client-side JavaScript. The token does not need to be submitted to AabiTech's server or an external decoding API for the decoding operation.

Even when a tool performs processing locally, JWTs can contain authentication credentials or sensitive claims. Avoid sharing tokens unnecessarily and use appropriate caution with live production credentials.