JWT Decoder

|

Paste a JWT to decode it.

Paste a JWT and see the decoded header and payload as formatted JSON. The signature is shown but not verified — decoding is read-only and happens entirely in your browser.

What is inside a JWT

A JWT is three Base64url-encoded segments joined by dots: header.payload.signature.

Header contains alg (the signing algorithm: HS256, RS256, ES256, etc.) and typ ("JWT"). Tokens with key rotation also include kid (key ID) to indicate which key was used.

Payload contains claims. Standard claims: sub (subject — typically a user ID), iat (issued at — Unix timestamp in seconds), exp (expiry — Unix timestamp in seconds), iss (issuer), aud (audience). Applications add custom claims for roles, permissions, tenant IDs, feature flags, and so on.

Signature is the cryptographic value that proves the token was signed by the issuer. It cannot be verified without the corresponding secret or public key.

Header{"alg":"HS256","typ":"JWT"}
Payload{"sub":"u_123","exp":1700000000,"iat":1699996400,"role":"admin"}

What decoding does and does not do

Decoding reads the Base64url-encoded header and payload and displays them as JSON. It does not verify the signature.

Signature verification requires the secret (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). Verification happens on your server or in your auth library — never skip it in production.

A decoded JWT is useful for inspecting claims during development. It is not a substitute for verification.

Never make authorization decisions based on decoded JWT content without server-side signature verification. The payload is readable by anyone who holds the token — only the signature provides authenticity guarantees.

Common debugging tasks

Checking expiry — convert the exp claim using the Timestamp Converter and compare to now. If exp is in the past, the token has expired.

Checking the issued-at time — iat tells you when the token was created. Useful when debugging "token too old" errors.

Algorithm mismatch — if your server expects RS256 but the token header says HS256, authentication will fail. The header shows the algorithm that was used to sign.

Missing claims — custom claims expected by your application (roles, tenant_id, permissions) should be present in the payload. If they are absent, the token was issued by a different version or configuration of your auth system.

Frequently Asked Questions

Is it safe to paste a JWT here?
The tool runs entirely in your browser and sends no data to a server. For production tokens with sensitive claims, be aware of who has access to your screen or clipboard. For development tokens, there is no risk.
Why does the tool show the signature but not verify it?
Signature verification requires the secret key or public key, which you never provide to a browser tool. Verification must happen on your server or in your application code using a trusted JWT library.
What does the algorithm field (alg) in the header mean?
It specifies the algorithm used to sign the token. HS256 uses HMAC with SHA-256 (symmetric — one secret key). RS256 uses RSA with SHA-256 (asymmetric — private key signs, public key verifies). ES256 uses ECDSA with P-256. None is a dangerous value that disables signature verification.
Why are the exp and iat values numbers, not dates?
JWT timestamps are Unix timestamps in seconds. Use the Timestamp Converter to read them as human-readable dates.

Related Tools