JWT Decoder

A JSON Web Token arrives as three blocks of Base64URL gibberish joined by dots, yet its first two parts are simply JSON that anyone holding the token is allowed to read: the header (algorithm and type) and the payload (the claims — subject, issuer, expiry and whatever the issuing system included). This decoder splits the token, decodes both parts and pretty-prints them so you can inspect exactly what a token asserts, convert its timestamps (exp, iat, nbf) into human dates, and debug why an API accepted or rejected it. Crucially, decoding happens entirely in your browser — tokens pasted here are never transmitted, which is the only safe way to inspect live credentials. Note what decoding is not: it does not verify the signature, it only reads.

Quick Answer: Paste a JWT to see its header and payload as readable JSON, with the expiry and issued-at claims converted into human dates.

Free Online Tool

Read what a token says — without sending it anywhere.

Your JWT

Header

Payload

How to Use the JWT Decoder

Copy the full token — all three dot-separated parts — from your header, storage or log.
Paste it into the box and press Decode Token.
Read the header (algorithm, type) and payload (claims) as formatted JSON.
Check the converted exp and iat times to judge whether the token is expired or not yet valid.
Clear the box when you are done; nothing was sent anywhere in the process.

Key Features

Decodes header and payload with clean JSON formatting.
Automatically converts exp, iat and nbf timestamps into readable dates.
Base64URL handled correctly, including missing padding.
Clear errors for malformed tokens rather than silent failure.
100% local decoding — the only safe way to inspect real tokens.

Best Practices and Tips

An expired-looking token that still fails usually has a wrong audience or issuer claim; compare aud and iss against what your API expects.
The signature proves a token is genuine; decoding only proves you can read it — never grant trust based on claims you decoded from an unverified token.
Check the alg in the header when debugging library mismatches; 'none' in a production token is a red flag worth investigating on the issuing side.
Short-lived access tokens (minutes) plus refresh tokens is the healthy pattern; a decoded exp days in the future on an access token is worth questioning.
When sharing a token in a bug report, redact it even though payloads look harmless — the signature still authorises access until expiry.

Common Mistakes to Avoid

Assuming a decoded token is a verified token — decoding reads claims; only signature verification validates them.
Pasting production tokens into random online decoders that transmit them to a server (this one does not).
Forgetting tokens expire in seconds-based Unix time; compare exp against current epoch, not against a wall clock in another format.
Truncating the token when copying from a wrapped log line, losing characters from the signature segment.

Frequently Asked Questions

What are the three parts of a JWT?

Header, payload and signature, joined by dots. The header states the signing algorithm and token type; the payload carries the claims (data); the signature is produced by the issuer with a secret or private key so receivers can verify the token was not altered.

Does decoding verify the token is genuine?

No. Decoding is reading, not verifying. Anyone can decode any JWT's payload — that is by design. Genuineness comes only from checking the signature with the issuer's key, which your API or auth library does; this tool intentionally does not ask for secrets.

Why does the payload show numbers for exp and iat?

Those claims are Unix timestamps in seconds — exp is when the token expires, iat when it was issued, nbf when it becomes valid. The tool converts them into dates alongside the raw values so you can judge the token's window at a glance.

Is it safe to paste a real token here?

Yes — this is exactly the scenario the tool was built for. All decoding runs as JavaScript in your browser tab; the token is never uploaded, logged or stored. Close the tab and it is gone.

My token only has two dots-worth of parts — what is wrong?

A JWT must have exactly three segments. Two segments means the copy was truncated (common when a log wraps) or it is not a JWT at all — perhaps a session ID or an opaque token, which cannot be decoded because it carries no readable data.