Key takeaways
- 01Decode any JWT and inspect header, payload, and standard claims in one paste.
- 02The exp, nbf, and iat claims are converted to human-readable timestamps with valid/expired tags.
- 03Decoding is purely local — safe for pasting real production tokens while debugging.
- 04The decoder does not verify signatures — that must happen server-side with the issuer's key.
Why You Need a JWT Decoder
JSON Web Tokens look like random noise until you know they are three Base64URL-encoded segments separated by dots. The first segment is the header (algorithm and token type), the second is the payload (the claims: user ID, roles, expiry), and the third is the signature. When debugging an authentication issue, an expired session, or a broken OAuth integration, the first thing you need to do is read the payload.
Doing that by hand means splitting on dots, decoding Base64URL, and then converting Unix timestamps to readable dates. Handytool's JWT decoder does all of that automatically and adds validity tags on the timing claims so you can see at a glance whether a token is still active.
How to Decode a JWT Token
- 01
Copy the JWT
Grab the token from your browser's DevTools (Application > Cookies, or the Network panel Authorization header), from a log file, or from your API client.
- 02
Paste it into the decoder
Paste the full token — including all three segments separated by dots — into the input box. The decoder identifies the segments automatically.
- 03
Read the header and payload
The tool splits the token and pretty-prints the header (algorithm, type) and payload (all claims) as formatted JSON.
- 04
Check the timing claims
The exp (expiry), nbf (not-before), and iat (issued-at) Unix timestamps are converted to ISO dates. The decoder tags exp as green (valid) or red (expired) relative to your current local time.
Standard JWT Claims Explained
These registered claim names appear in most JWTs.
- 01iss (Issuer) — identifies who created the token, typically a URL or service name.
- 02sub (Subject) — the principal the token represents, usually a user ID.
- 03aud (Audience) — the intended recipient(s) of the token; your server should reject tokens meant for others.
- 04exp (Expiration) — Unix timestamp after which the token must be rejected.
- 05nbf (Not Before) — Unix timestamp before which the token must be rejected.
- 06iat (Issued At) — Unix timestamp when the token was minted; useful for detecting stale tokens.
Safe to Paste Real Tokens While Debugging
JWT decoding happens entirely in your browser using the native atob function and JSON.parse. Nothing is transmitted to any server — your token is decoded in memory and displayed locally. You can safely paste real access tokens and session tokens from development or staging environments to debug authentication flows.
That said, treat JWTs like passwords. They grant access to your systems for their full lifetime. Do not paste production tokens from high-privilege accounts into any tool unless you are confident of the tool's privacy guarantees — and always rotate a token if you believe it may have been exposed.
JWT Decoder FAQ
What is a JWT?
A JSON Web Token is a compact, URL-safe format consisting of three Base64URL segments (header, payload, signature) separated by dots. JWTs carry claims — assertions about a user or session — and are used for authentication, authorization, and API access.
Does this decoder verify the JWT signature?
No. The decoder only parses the header and payload. Signature verification requires the issuer's secret or public key and must happen in your application code using a trusted library.
Is it safe to paste a real access token here?
Decoding is entirely local — the token is never transmitted. However, JWTs grant real access, so treat them like passwords. Do not share them, do not commit them to source control, and rotate them if they may have been exposed.
What does the exp claim mean?
exp is the expiration timestamp — a Unix integer representing the moment the token stops being valid. The decoder converts it to a human-readable ISO date and marks it valid or expired relative to your current local time.
Why is the JWT payload visible without a key?
JWT payloads are Base64URL-encoded, not encrypted. They are designed to be readable — the signature only proves authenticity, not confidentiality. Never put truly secret data in a JWT payload unless you use JSON Web Encryption (JWE).
Is the decoder free?
Yes. Handytool is free with no sign-up, no rate limits, and no data collection.