Local Tools Online

JWT Decoder

Paste a JSON Web Token and instantly see its decoded header and payload, formatted and readable — without the token ever leaving your browser.

Why a JWT decoder needs to be local, not optional

A JWT is arguably the single most sensitive string a developer regularly pastes into a random web tool. It’s a live authentication credential — decoding one doesn’t require a password, and if the token hasn’t expired, whoever has the raw string can often use it to impersonate the associated session or account. Pasting a production JWT into a server-side decoding tool means that server now has a working copy of a live credential, whether or not the tool’s operator intends to do anything with it.

This decoder works purely by parsing the Base64URL-encoded header and payload segments of the token client-side — the exact same operation your browser’s JavaScript engine could do with a few lines of code, just wrapped in a readable interface. The signature segment is displayed but never verified against a secret (verification would require the signing key, which you should never paste into any tool, this one included).

How to use it

  1. Paste the full JWT string (the three dot-separated segments: header.payload.signature).
  2. The header and payload decode instantly into formatted, syntax-highlighted JSON.
  3. Common claims are annotated automatically — exp and iat are converted from Unix timestamps into human-readable dates, and an “expired” or “valid until” badge shows at a glance whether the token is still live.
  4. The signature segment is shown as raw Base64 but is never decoded or verified, since that requires a secret key this tool intentionally never asks for.
  5. Copy the decoded header or payload independently if you just need one or the other for debugging.

Common situations this solves

  • Debugging why an API call is being rejected as unauthorized by checking whether the token has actually expired or is missing an expected claim.
  • Verifying which scopes or roles are embedded in a token during OAuth or SSO integration work.
  • Checking the algorithm used to sign a token (alg field in the header) when investigating a security review or a library compatibility issue.
  • Confirming the issuer (iss) and audience (aud) claims match what’s expected when debugging a multi-service auth setup.
  • Inspecting a token from a support ticket or bug report a user has shared, without needing to spin up your own decoding script.

Frequently asked questions

Can this tool verify if a token’s signature is valid? No, intentionally. Verifying a signature requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256/ES256). This tool only decodes and displays the header and payload — it never asks for or handles a signing key, which is a deliberate design choice to avoid becoming a tool people might misuse to check secrets against tokens.

Is it safe to paste a real, live JWT into this? It’s meaningfully safer than a server-side decoder because nothing is transmitted, but the general advice still holds: avoid pasting live production tokens into any tool, local or not, if you can regenerate a test token instead. For debugging, prefer using a short-lived test token or a token from a non-production environment when possible.

Why does the expiration show a date, but the raw payload shows a random number? JWTs store timestamps as Unix time (seconds since January 1, 1970) for compactness and to avoid timezone parsing issues. The tool converts fields like exp, iat, and nbf into a readable local date and time automatically, while still showing the raw number for reference.

What does it mean if the header shows "alg": "none"? This is a red flag if you see it on a token in an active system — alg: none means the token is unsigned, and depending on how a server validates tokens, this has historically been exploitable to bypass signature verification entirely. Its presence on a real token you’re investigating is worth flagging immediately.

Can I decode a token that isn’t a standard JWT, like an opaque access token? No — opaque tokens (common with some OAuth providers) are just random strings with no embedded structure, so there’s nothing to decode. Only tokens following the three-segment header.payload.signature JWT structure will decode meaningfully here.