JWT Decoder & Claims Explainer
Decode and inspect a JWT locally. Signature is not verified. Your token is never uploaded.
This tool decodes a JWT for inspection only. It does NOT verify the signature. A decoded token may have been tampered with. Never trust a JWT's contents in production code without verifying the signature against the issuer's key.
What this tool does
A JSON Web Token (JWT) is three base64url-encoded strings joined by dots: a header that describes the signing algorithm, a payload that holds the claims (the actual data the token carries), and a signature that proves the token came from the expected issuer. This tool splits a JWT into its three parts, base64url-decodes the header and payload, parses them as JSON, and explains any standard claims it finds. The signature is shown but not verified. Everything happens in your browser.
How to use it
Paste your JWT into the input box and press Decode. You will see the header
and payload as formatted JSON, plus a small table that translates standard claims like
iss, sub, aud, exp, and iat
into plain English. If the token is malformed (wrong number of segments, invalid base64, or
not valid JSON), you will see a specific error message.
Common use cases
- Debugging an auth flow by inspecting what the issuer actually put inside the token.
- Confirming a token has not expired (the
expclaim is a Unix timestamp; the table converts it). - Finding the user identifier (
sub) or audience (aud) at a glance. - Sanity-checking that a refresh-token rotation issued a new token rather than the same one.
- Inspecting third-party tokens (OAuth, OpenID Connect) when integrating with an external provider.
Common pitfalls
- Signature not checked. A decoded JWT can be edited and still decode cleanly. Production code must verify the signature against the issuer's public key (or shared secret for symmetric algorithms) before trusting any claim. This tool is for inspection, not verification.
- Sensitive data in payload. JWT payloads are encoded, not encrypted. Anyone with the token can read every claim. Do not store passwords, secrets, or personally identifying data you would not put in plaintext.
- "alg: none" tokens. Some libraries historically accepted JWTs with the
algorithm set to
none, treating them as valid without checking the signature. This is a known vulnerability. If you seealg: nonein the header of a token your system trusts, treat it as a bug to fix immediately.
Frequently asked questions
- What is a JWT and how is it structured?
- A JSON Web Token (JWT) is three base64url-encoded segments joined by dots: header.payload.signature. The header describes the signing algorithm. The payload holds the claims (the actual data). The signature proves the token came from a trusted issuer. The header and payload are not encrypted; they are encoded so they can be transmitted as text.
- Does this tool verify the JWT signature?
- No. This tool decodes the header and payload for inspection but does not verify the signature. Verification requires the issuer key, which is not available client-side for tokens you did not issue. Production code MUST verify signatures before trusting any claim. Use this tool to read tokens; use a server-side library to verify them.
- Are JWTs safe to store sensitive data in?
- No. JWT payloads are base64url-encoded, not encrypted. Anyone with the token can read every claim. Do not store passwords, API secrets, full credit-card numbers, or anything you would not put in plaintext. If the token must carry sensitive data, use JWE (encrypted JWT) instead.
- What does "alg: none" mean in a JWT header?
- It means the token has no signature. Several JWT libraries historically accepted alg: none tokens as valid without checking the signature, which is a serious vulnerability. Modern libraries reject alg: none unless explicitly configured to allow it. If you see alg: none in a token your system trusts, treat it as a bug to fix immediately.
- What are the standard JWT claims (iss, sub, aud, exp, etc.)?
- iss is the issuer (who minted the token). sub is the subject (often a user id). aud is the audience (who the token is for). exp is the expiration time as a Unix timestamp. nbf is the earliest time the token is valid. iat is when the token was issued. jti is a unique token identifier. The tool shows these in a translated table when present in the payload.
- How do I tell if a JWT is expired?
- Check the exp claim against the current Unix time. The tool converts exp into an ISO timestamp in the claims table for human readability. A token whose exp is in the past should be rejected by any production code, even if its signature is valid.
- Can I edit a decoded JWT and use it?
- You can edit the JSON, but the edited token will fail signature verification by the issuer. Editing the header or payload changes the data the signature was computed over, so the original signature no longer matches. Production systems MUST verify signatures, so a tampered token is rejected.
Cite this tool
For academic, journalistic, or technical references. Pick a format:
Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.