JWT Decoder

A JWT decoder lets you inspect the readable contents of a JSON Web Token by decoding its Base64URL-encoded header and payload into JSON. JWTs are commonly used to carry claims in authentication and API workflows.

A typical signed JWT contains three dot-separated parts: a header, a payload and a signature. The header describes token metadata, the payload contains claims, and the signature supports cryptographic verification.

Decoding is not the same as verifying a signature. Use this tool to inspect token contents and troubleshoot claims, but never treat successful decoding as proof that a token is authentic.

To decode a JWT, paste the complete token into the JWT Decoder and select Decode JWT. A standard signed JWT has three parts separated by periods:

header.payload.signature

The decoder reads the Base64URL-encoded header and payload and displays their contents as JSON. Review the algorithm metadata, claims and time values to understand what the token contains.

If you copied the token from an HTTP authorization header, remove the Bearer prefix and surrounding whitespace before decoding. The prefix is part of the authorization scheme, not the JWT itself.

A typical signed JSON Web Token consists of three Base64URL-encoded parts separated by periods. Each part serves a different purpose.

• Header: Metadata such as the signing algorithm in alg and token type in typ.
• Payload: Registered and custom claims describing the token subject, audience, expiry or application-specific information.
• Signature: A cryptographic value used to verify that the encoded header and payload have not been altered, when checked with the correct algorithm and key.

Header and payload encoding is not encryption. Anyone who obtains an ordinary signed JWT can generally read these sections, so avoid placing confidential information in them without an appropriate protection mechanism.

JWT claims are statements carried in the token payload. Common registered claims include iss, sub, aud, exp, nbf, iat and jti.

• iss: The issuer of the token.
• sub: The subject represented by the token.
• aud: The intended audience.
• exp: The time after which the token must not be accepted.
• nbf: The time before which the token must not be accepted.
• iat: The time the token was issued.
• jti: An identifier that can distinguish one token from another.

Applications may also define custom claims for roles, permissions or tenant identifiers. Whether a claim is trustworthy depends on successful validation and verification, not merely on its presence in decoded JSON.

The JWT exp claim indicates the time after which a token must not be accepted. JWT NumericDate time claims are generally expressed as seconds since the Unix epoch, rather than milliseconds.

This decoder displays supported time claims in a human-readable format so you can inspect expiry and issuance values while troubleshooting. The iat claim records issuance time, while nbf identifies the time before which the token should not be accepted.

When comparing these values with application logs or other timestamps, check the time unit and timezone carefully. A decoded expiry value alone does not validate the token or account for every server-side validation rule.

JWT decoding and JWT signature verification are separate operations.

Decoding converts the encoded header and payload into readable data. For a typical signed JWT, this does not require a signing secret or public key.

Verification checks the signature using the expected algorithm and appropriate key. A secure validation process may also check issuer, audience, expiry and other application-specific requirements.

A token can decode correctly and still be forged, expired or intended for another application. Never use decoded claims alone to make authentication or authorization decisions.

You can normally decode the header and payload of a signed JWT without knowing its signing secret or private key. These parts use Base64URL encoding, which represents data in a token-friendly format but does not encrypt or conceal it.

The appropriate key is needed for signature verification, depending on the signing algorithm. Reading the claims therefore does not prove who issued the token or whether its contents are authentic.

For a closer look at the encoding format, use the Base64 Encoder & Decoder to explore the difference between encoded data and encryption.

Not every JWT is encrypted. A common signed JWT uses the JSON Web Signature (JWS) format, with a header, payload and signature. The header and payload are Base64URL-encoded, not hidden through encryption.

Encrypted JWTs can use the JSON Web Encryption (JWE) format, which has a different structure and requires the appropriate decryption key to read protected content. A standard three-part signed token should not be assumed to provide confidentiality.

Do not put passwords, private keys or other confidential values in an ordinary JWT payload. Use an appropriate security design when data confidentiality is required.

JWT decoding is useful when debugging API authentication, access tokens and identity-provider integrations. Inspect the header and payload to check expected claims, the declared signing algorithm and timestamps such as iat, nbf and exp.

Common troubleshooting clues include a missing audience, an unexpected issuer, an expired token, a not-yet-valid token or a claim whose value differs from what the application expects. For JSON readability, the JSON Formatter & Validator can also help you inspect structured JSON data.

These checks help diagnose configuration issues but do not replace server-side signature verification and validation of the claims required by your application.

AabiTech processes JWT decoding in your browser with client-side JavaScript. The decoding operation does not need to send the token to AabiTech servers or an external decoding API.

Local processing reduces unnecessary transmission, but it does not make every token safe to share. Live JWTs may act as bearer credentials or reveal sensitive claims, so avoid posting them publicly, sending them to others or exposing them in screenshots.

For production troubleshooting, use test tokens where possible and follow your organization’s credential-handling rules. Decoding reveals token contents; it does not confirm that the token is valid or safe to use.