About the Handiwork JWT Decoder
The JWT Decoder splits a JSON Web Token into its header and payload so you can inspect its claims at a glance. Standard time claims like expiry (exp), issued-at (iat), and not-before (nbf) are translated into human-readable dates, and decoding happens entirely in your browser so tokens never leave your machine. Decoding is inspection only: this tool never verifies the signature or decides whether a token should be trusted.
How to use the Handiwork JWT Decoder
- Paste your JSON Web Token into the input.
- Read the decoded header and payload as formatted JSON.
- Inspect the time claims, then verify the signature and required claims in the trusted receiving service.
What is inside a JWT?
A JSON Web Token has three base64url-encoded parts separated by dots: a header describing the signing algorithm, a payload containing claims such as the subject, issuer, audience, and expiry, and a signature. The header and payload are encoded, not encrypted, so anyone holding the token can read their contents.
Decoding is not verifying
A valid-looking payload does not prove that its issuer created it or that it has not been changed. Verification must enforce an allowed algorithm, validate the signature with the correct key, and check the issuer, audience, expiry, not-before time, and any application-specific requirements before authentication or authorization.
How time claims are interpreted
The exp, iat, and nbf registered claims use NumericDate values: seconds since the Unix epoch. The decoder formats finite numeric values and compares exp with the current device time. An expired label is a convenience check, not proof that a token was issued legitimately or that a server will accept it.
Worked inspection workflow
When debugging a token, first confirm there are three dot-separated segments. Inspect alg and typ in the header, then review iss, aud, sub, exp, iat, and nbf in the payload. Compare those values with the receiving service configuration. Perform actual signature and claim validation in the trusted backend—never make an authorization decision from this decoded display.
Assumptions and limitations
- The signature is displayed but never cryptographically verified.
- Issuer, audience, subject, nonce, scope, and application-specific claims are not validated.
- Expiry is compared with the device clock and does not apply a server-specific clock-skew allowance.
- A decoded token may contain active credentials or personal data; avoid sharing screenshots or pasting production tokens on untrusted devices.
Sources and standards
These authoritative references were used to verify the method and guidance on this page.
Frequently asked questions
Does this verify the JWT signature?
No. It only decodes the header and payload for inspection. Signature verification requires the correct key and validation policy and should be done by the trusted receiving service.
Is my token sent anywhere?
No. Decoding runs entirely in your browser, so your token and its claims are not uploaded by this tool.
Why does it say my token is expired?
If the payload contains a numeric exp claim whose time is in the past, the decoder marks it expired by comparing it with your device clock.
Is Base64URL encoding encryption?
No. The header and payload can be decoded by anyone who has the token. Do not put secrets in JWT claims unless a separate encryption design protects them.
Can I trust a token when the dates look correct?
No. Dates are only some of the claims a service may enforce, and this display does not verify the signature, issuer, audience, nonce, or application policy.