JWT Decoder

What can a JWT Decoder show?

A JWT decoder helps inspect the token header, payload, and common claims such as exp, iat, and nbf while debugging API and authentication flows.

Decoding a JWT is not the same as verifying it. A decoded token can still be forged or expired unless the signature and claims are validated by the system that trusts it.

JWT structure and registered claims

A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object, usually just alg, the signing algorithm the issuer claims to have used, and typ, normally the literal string JWT. The payload is a JSON object holding whatever claims the issuer chose to include. Base64url is base64 with two substitutions, plus becomes hyphen and slash becomes underscore, and its padding equals characters removed, which is why a token can sit directly in a URL or an HTTP header without further escaping. This decoder reverses that encoding with atob() after restoring the standard base64 alphabet and padding, then parses the result with JSON.parse(). The third segment, the signature, is shown exactly as received and is never decoded, because it is a raw cryptographic value, not JSON.

The payload can hold any JSON, but RFC 7519 registers seven standard claim names that most systems reuse:

This tool converts exp, iat, and nbf to ISO 8601 next to the raw Unix timestamp, and states whether exp has passed compared to the current time on your device. It does not treat iss, sub, aud, or jti specially; those still appear in the decoded payload JSON, just without a dedicated row.

The caveat that matters most: decoding is not verifying. Verifying a JWT means checking the signature in the third segment against a secret or public key, confirming iss and aud match what the relying system expects, and confirming exp and nbf against the current time before trusting any claim. This tool performs none of that. Anyone can write a header and payload with any claim values, base64url-encode them, and the result decodes here exactly like a token issued by a real authorization server. A decoded payload is only as trustworthy as the verification step a receiving system is supposed to perform afterward.

Worked example

The sample button on this page loads a token built from this header and payload:

Joined with the signature part, the full token is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJDb252ZXJ0VW5saW1pdGVkIPCfkYsiLCJsb2NhbGUiOiJ0aC1USCIsImlhdCI6MTc3ODUyOTYwMCwibmJmIjoxNzc4NTI5NjAwLCJleHAiOjE4MTAwNjU2MDB9.sample-signature-not-verified. The signature part is deliberately a plain label here, not an HMAC, so nobody mistakes the sample for a token that would pass real verification. Decoding the payload gives iat and nbf of 1778529600, which is 2026-05-11T20:00:00.000Z, and exp of 1810065600, which is 2027-05-11T20:00:00.000Z; the claims panel reports whether that exp is already in the past compared to the current time on your device.

Limits and gotchas

• Decode is not verify. This is the single most important limit: the tool never checks the signature, so a token with a forged payload, a rolled-back exp, or entirely fabricated claims decodes exactly like a legitimate one. Trust decisions belong on the server that issued the token, not in this viewer.
• No protection against unsafe algorithms. Because signatures are never checked, the tool has no opinion on a header claiming alg: none or another weak setting; it is displayed as-is with no warning.
• Strict base64url and JSON required. Decoding requires exactly three dot-separated segments, valid base64url characters, and JSON that parses cleanly. A token truncated by copy-paste, or one using standard base64 with plus and slash instead of base64url, is rejected with a malformed-input message rather than partially decoded.
• exp, iat, and nbf must be Unix seconds. Per RFC 7519 these are NumericDate values in seconds since the epoch. If an integration accidentally stores milliseconds in exp, this tool computes the wrong ISO date and the wrong expired-or-active status, since it multiplies the raw value by 1000 assuming seconds.
• Other registered claims are not summarized. iss, aud, and jti still appear in the decoded payload JSON, but only exp, iat, and nbf get a dedicated claims row with a converted date.
• Treat pasted tokens as visible text. Base64url is an encoding, not encryption; anyone who can read the segments can read the payload without any key, so a production token pasted here should be assumed fully readable, not confidential.

Frequently Asked Questions

Does this verify JWT signatures?

No. It decodes the header and payload only.

Is my JWT sent to ConvertUnlimited servers?

No server-side upload endpoint is used for decoding; token contents are decoded locally in your browser.

Can I inspect exp and iat claims?

Yes. Unix timestamp claims are shown as ISO dates when present.

Should I paste production tokens?

Avoid pasting sensitive production tokens unless you understand the risk.

Does it support Unicode claims?

Yes. UTF-8 payload content is decoded safely.

What are the standard JWT claims?

RFC 7519 registers iss, sub, aud, exp, nbf, iat, and jti. This tool highlights exp, iat, and nbf with converted dates; the rest still appear in the decoded payload JSON.

Why did decoding fail with a malformed token message?

The tool expects exactly three dot-separated segments using the base64url alphabet. A token that was line-wrapped, truncated, or copied using standard base64 instead of base64url fails this check.

What does alg in the header mean?

It names the signing algorithm the issuer claims to have used, such as HS256 or RS256. This tool displays it but never checks whether the signature actually matches that algorithm.

Privacy

Privacy build: This build removes ads, analytics, remote fonts, runtime CDN scripts, and file-operation telemetry. Selected files are processed in the browser using local JavaScript and browser APIs.

ConvertUnlimited does not provide a server-side upload endpoint for this JWT decoding flow. Token contents are decoded locally in your browser.

Terms of Use

ConvertUnlimited is provided as is. Do not rely on decoded JWT output as proof of token validity.