JWT Decoder

When do you need to decode a JWT without verifying it?

What this tool does

The Kitnax JWT Decoder splits a JSON Web Token into its three parts — header, payload, and signature — and displays the decoded JSON for the first two segments. Standard claims such as exp, iat, sub, and iss appear as readable chips alongside formatted JSON you can copy. Expiry warnings highlight tokens whose exp timestamp is in the past relative to your clock. Parsing happens entirely in your browser; no token data is sent to Kitnax servers or third-party APIs.

Why you need it

JWTs carry authorization context in OAuth flows, microservice gateways, and single sign-on integrations, but the compact string format hides details until you decode it. During development you need to confirm which algorithm the header declares, whether the audience claim matches your API, or why a gateway returns 401 despite a seemingly valid session. Decoding is a debugging step — it answers "what claims does this token contain?" without replacing server-side signature verification. Production authentication must always validate signatures with issuer keys; a decoded payload alone proves nothing about trustworthiness.

How to use it

1. Paste a JWT string (header.payload.signature) into the Token field or click Load Sample for a demo token.
2. Click Decode to parse the three segments — decoding also runs as you edit when the format is valid.
3. Review the HEADER panel for alg, typ, and kid values that tell you how the token was signed.
4. Inspect PAYLOAD claims, paying attention to exp warnings and standard fields rendered as chips.
5. Copy header, payload, or signature segments individually when filing bug reports or comparing environments.

Practical examples

• OAuth debugging: decode an access token from your identity provider and confirm the scp or roles claim matches what your API middleware expects.
• SSO integration: compare iat and exp on tokens issued by different environments to diagnose clock skew or overly short lifetimes.
• Gateway troubleshooting: verify that alg in the header is RS256 while your service still validates with an outdated HS256 secret.
• Learning JWT structure: load the sample token and trace how Base64URL-encoded JSON maps to the three dot-separated parts.

How it works

A JWT is three Base64URL-encoded segments joined by dots. The header JSON typically includes alg (signing algorithm) and typ (token type). The payload holds claims — registered names like exp and custom application fields. The signature is a cryptographic MAC or asymmetric signature over header and payload; verifying it requires the issuer's secret or public key and is intentionally out of scope for this decoder.

Kitnax Base64URL-decodes the first two segments and pretty-prints the JSON. The signature segment is shown as encoded text so you can copy it, but this tool does not recompute or validate it. That distinction matters for production auth: an attacker can craft a payload with admin claims and leave the signature unchanged or set alg to none — only signature verification on your backend prevents that. Decoding is safe for inspection when you understand the limits; trusting decoded content without verification is not.

All processing stays client-side. Tokens are not logged or transmitted.

Common mistakes

• Assuming a successfully decoded token is authentic — decode reveals content; verify signatures on the server before granting access.
• Ignoring alg in the header and validating with the wrong key type (symmetric vs asymmetric).
• Pasting long-lived production tokens into shared screens or recordings even when tooling runs locally.
• Expecting opaque refresh tokens to decode — many providers store refresh tokens as random strings, not JWTs.

FAQ

Related tools

• JWT Encoder
• Base64 Encoder/Decoder
• Hash Generator
• URL Encoder/Decoder