CodeKitHubWhat Is This Tool?
A JWT (JSON Web Token) is a compact, URL-safe string used to carry claims between two parties — most commonly as an auth token after login. It has three dot-separated parts: a header (algorithm and token type), a payload (the actual claims — user ID, roles, expiry, etc.), and a signature (used by the server to verify the token wasn't tampered with).
The header and payload are just Base64URL-encoded JSON — not encrypted — so anyone can decode and read them without a secret key. Only the signature requires a secret to verify. That's exactly what this tool does: decode the readable parts and show them as formatted JSON, without attempting to verify the signature.
Why Use It?
- Instantly readable header and payload, formatted as JSON — no more manually splitting the string and Base64-decoding it by hand.
- Automatic expiry check: if the payload has an "exp" claim, it's converted to a readable date and flagged as expired or valid.
- One-click copy for header or payload separately.
- 100% client-side — the token is decoded locally and never transmitted, safe to use even with tokens from a production system.
- No signature verification performed or claimed — this is a debugging/inspection tool, not a validator.
How to Use
- Paste your JWT into the box (the full string, including all three dot-separated parts).
- The header and payload decode automatically as you type.
- Check the expiry line if the token has an "exp" claim — it shows the exact date and whether the token has expired.
- Click "Copy" under either box to copy that section as JSON.
Example
Input
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjoxNzAwMDAwMDAwfQ.dQw4w9WgXcQOutput
Header: {"alg": "HS256"}
Payload: {"sub": "1234", "name": "John Doe", "exp": 1700000000}The signature (third part) is never decoded or checked — it's an opaque hash used server-side to verify authenticity.
Practical tips
- Debugging "invalid token" errors: decode the payload first to check the "exp" claim — an expired token is the most common cause, and it's not always obvious from the error message alone.
- Checking what a third-party API's token actually contains: many APIs return an opaque-looking JWT as an access token — decode it here to see the scopes, user ID, or expiry your integration is actually receiving.
- Never assume a JWT is encrypted: if you see sensitive data (email, internal IDs) in a decoded payload during development, that's a signal to move that data server-side rather than trust the client not to read it.
Common claims you'll see in a payload
| Claim | Meaning |
|---|---|
| sub | Subject — usually the user ID the token represents |
| exp | Expiration time (Unix timestamp) — token is invalid after this |
| iat | Issued at — when the token was created |
| iss | Issuer — which service/server issued the token |
| aud | Audience — which service the token is intended for |
| role / roles / scope | Custom claims — permissions or roles granted to the user (not part of the JWT standard, but extremely common) |
Frequently Asked Questions
Does this tool verify the JWT signature?
No. Verifying a signature requires the secret key or public key used to sign the token, which only the issuing server has. This tool only decodes the header and payload — the human-readable parts — so you can inspect claims and expiry without needing any key.
Is it safe to paste a real production JWT here?
Decoding happens entirely in your browser via JavaScript — the token is never sent to any server, including ours. That said, treat tokens like passwords: don't paste them into tools you don't trust, and avoid sharing screenshots of decoded tokens that contain sensitive claims.
Why can anyone read my JWT's payload without a password?
By design — a JWT's header and payload are Base64URL-encoded, not encrypted. Encoding is not security; it just makes the JSON URL-safe to transmit. Never put secrets (passwords, credit card numbers) directly in a JWT payload — assume anyone who has the token can read its contents.
What does the "exp" claim mean and why does it matter?
"exp" is the token's expiration time, as a Unix timestamp (seconds since 1970). Servers reject a JWT once this time has passed, forcing the client to re-authenticate. This tool converts it to a readable date and flags whether it's already expired, which is useful for debugging "why did my session log out" issues.
My token shows a JSON parse error — why?
Either the string isn't a valid JWT (should be exactly three dot-separated parts), or it's been truncated or altered — a common cause is a token accidentally split across multiple lines or missing trailing characters when copied.