JWT Decoder — Decode JSON Web Tokens
Paste a JWT token to instantly decode and inspect its header and payload. View claims like user ID, role, and expiry in readable JSON. Useful for debugging authentication issues, inspecting token contents during development, and understanding what a JWT actually carries. This tool only decodes — it does not validate signatures.
How to Decode a JWT
- 1Paste your JWT token into the input field
- 2The header and payload are decoded and displayed as formatted JSON
- 3Inspect claims like exp, iat, sub, and iss
- 4Note: this tool does not validate the signature
Key Benefits
- Instantly decodes header and payload into readable JSON
- Shows all standard and custom claims at a glance
- Handles standard and URL-safe Base64url encoding
- Runs entirely in your browser — the token is never transmitted anywhere
Frequently Asked Questions
What is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format used to pass claims between two parties — typically a client and a server. It consists of three Base64url-encoded parts separated by dots: a header (algorithm and token type), a payload (claims such as user ID, role, and expiry), and a signature. JWTs are the most common token format for stateless authentication in REST APIs and single-page applications.
Is it safe to paste my JWT here?
This tool decodes entirely in your browser — no token data is sent to any server. That said, treat JWTs as sensitive: a valid, non-expired token may grant access to protected resources. Prefer pasting tokens from a development or staging environment. Invalidate any production token you paste into any external tool as soon as debugging is complete.
Why doesn't this tool validate the signature?
Validating a JWT signature requires the secret (for HS256) or the public key (for RS256/ES256) used to sign it. You should never share these with a third-party tool. The header and payload are plain Base64url data — no secret is needed to read them. Signature verification belongs in your server-side authentication code, not in a browser-based decoder.
What do common JWT claims mean?
Standard registered claims: iss (issuer — who issued the token), sub (subject — usually the user ID), aud (audience — intended recipient), exp (expiration — Unix timestamp after which the token is invalid), iat (issued at — when it was created), and nbf (not before — earliest valid time). Applications add custom claims like role, email, or permissions on top of these. The exp claim is the most commonly inspected when debugging authentication problems.
What is the difference between decoding and verifying a JWT?
Decoding reads the Base64url-encoded content — anyone can do it with no key required, as this tool demonstrates. Verifying checks that the signature was produced by the expected party using the correct secret or key, that the token has not been tampered with, and that claims like exp have not been exceeded. A decoded token tells you what it claims; a verified token tells you those claims can be trusted. Never use a decoded-only token to make authorization decisions.
Should I store sensitive data in a JWT payload?
The payload is Base64url-encoded, not encrypted — anyone with the token can decode and read its contents instantly, as this tool shows. Avoid putting passwords, payment details, or confidential data in the payload. Stick to non-sensitive identifiers like user ID, role, and session ID. If you need the payload to be confidential, use JWE (JSON Web Encryption) instead of a plain signed JWT.