What the JWT Decoder Does
The JWT Decoder takes a JSON Web Token and prints what is actually inside it. Paste the token into the input panel and run the transform — there are no options to configure — and the output panel shows a small JSON report with the decoded header, the decoded payload, and a description of the signature segment. An info line under the output names the token's algorithm and, if the payload carries an exp claim, whether it has already expired.
The tool is deliberately decode-only. It never asks for a secret or a public key, and it does not attempt signature verification — that job belongs to the
JWT HS256 Verifier and
JWT RS256 Verifier. Decoding is the read-the-token step; verification is the trust-the-token step, and the two should not be confused.
How the JWT Decoder Works
A compact JWT — the form every Authorization: Bearer header carries — is three strings joined by dots: header.payload.signature. Each string is Base64Url-encoded: standard Base64 with + swapped for -, / for _, and the = padding stripped, so the token survives inside URLs, headers, and cookies without escaping. The encoding is transport, not encryption — anyone who has the token can read every byte of the header and payload, which is precisely why this tool can exist.
The decode path is short and mechanical. The input is trimmed and split on .; the first segment is Base64Url-decoded and parsed as JSON to yield the header, then the same runs on the second segment for the payload. The header normally names the signing algorithm (alg) and the token type (typ); the payload carries the claims — sub for the subject, iss for the issuer, exp for expiry as seconds since the Unix epoch, iat for issued-at, plus whatever custom claims your service adds.
The signature segment is handled differently, and the difference is the point. The tool never decodes it — the signature is raw hashed bytes, not JSON — and instead reports the first 16 characters followed by its total length, so you can compare two tokens at a glance or confirm a signature is present without pretending to read it. A two-segment token reports (unsigned), which is the shape an alg:none token takes.
The info line assembles the quick answers: it always names the algorithm from the header, and if the payload defines exp it converts the epoch-seconds value to an ISO timestamp and appends EXPIRED or valid as of the moment you ran the tool.
Using the JWT Decoder
- Step 1 — Paste the complete token. Copy the whole JWT from your browser's devtools (Network tab, request headers), your application logs, or your storage inspector. Leading and trailing whitespace is fine; the tool trims it. A token shorter than two segments is rejected with an explicit error.
- Step 2 — Run the transform. There are no options, no algorithm selector, and no key fields. The absence is deliberate: decoding needs nothing but the token.
- Step 3 — Read the JSON report. The output is pretty-printed JSON with three keys.
header shows the algorithm and token type; payload shows every claim verbatim; signature shows the 16-character prefix and the full length, or (unsigned) for a two-segment token. - Step 4 — Check the info line. Below the output, the info line reads like
Algorithm: HS256, plus · exp 2026-01-01T00:00:00.000Z (EXPIRED) or (valid) when an expiry claim exists. This is the fastest answer to "why did my request start failing?" - Step 5 — Escalate to verification when it matters. If the payload claims matter — a role, a tenant ID, a session identity — take the same token to the HS256 or RS256 verifier with the corresponding key. Decode first to learn the algorithm; verify before you trust.
Common Use Cases
Debugging a 401 or 403. Decode the token and read the claims: is sub the user you authenticated as, is the role or scope claim what you expected, has exp passed, does the issuer match what the API verifies. A surprising number of auth bugs are visible in the payload alone.
Inspecting a third-party identity token. OAuth and OIDC providers hand your application an id_token. Before wiring code around it, decode one and see exactly which claims the provider populates — the answer differs between Google, Auth0, Azure AD, and in-house issuers, and the claim names you assume are often not the ones you receive.
Auditing what your own tokens leak. Payloads are readable by anyone who intercepts the token, so paste a production-shaped token here and check whether someone put email addresses, names, or internal identifiers into claims. Anything you would not print on a lanyard does not belong in an unencrypted payload. Reading iat and exp side by side also shows the effective session length your auth service issues — the input to sensible refresh-token design.
Worked Example
Take the canonical demonstration token, signed with HS256 under the secret secret:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.1VAmegkQOBsQ-iSZU96z6c8NY7QR9OhhYWYHwHTeGT4
Paste it and run the transform. The output panel shows:
{
"header": { "alg": "HS256", "typ": "JWT" },
"payload": { "sub": "1234567890", "name": "Jane Doe", "iat": 1516239022 },
"signature": "1VAmegkQOBsQ-iSZ… (43 chars)"
}
The info line reads Algorithm: HS256 — no exp claim exists in this payload, so no expiry status is appended. Every value above is now readable: the token was issued in January 2018 (per iat), names subject 1234567890, and carries a plain name claim — exactly the kind of personal data a leak audit would flag. The signature prefix matches the first 16 characters of the original third segment.
Two failure shapes are worth seeing once. Drop the third segment and the tool still decodes, reporting (unsigned). Replace a payload character before the final dot and the payload still decodes — to different claims. Neither produces an error, and that is the lesson: decoding validates shape, not truth.
Tips and Common Mistakes
- Decoding is not verification. The tool will happily show you a token whose signature is garbage, whose payload was edited after signing, or whose
alg is none. Treat decoded claims as unverified until a verifier has checked the signature with the right key. - Do not paste high-value tokens into tools you do not control. This one runs entirely in your browser and transmits nothing — but that reasoning must hold for every tool you paste a live token into. When in doubt, mint a short-lived test token with the same shape.
exp is seconds, not milliseconds. A payload with "exp": 1735689600000 encodes a date roughly 55,000 years out. If an expiry looks absurd, check the units before blaming the library.- Encrypted JWTs will not decode. A JWE (encrypted JWT) has five dot-separated segments, not three, and its payload is ciphertext. If your token has five parts, this decoder is the wrong tool — the payload is not meant to be readable without the decryption key.
- The truncated signature is for reading, not for verifying. Only 16 characters are shown. Copy the original token from its source when you move to a verifier — never re-type or reconstruct a signature from the display.
- A parse error usually means it is not a JWT. Opaque session IDs, base64 blobs, and SAML fragments all fail with an explicit JSON error. For a friendly best-effort attempt at arbitrary tokens — JWT first, then plain Base64 — use the Session Token Decoder.
Frequently Asked Questions
Does the JWT Decoder verify the signature?
No. It decodes the header and payload and describes the signature, but performs no cryptographic check — verification needs the signing key, which the tool deliberately never requests. There is no key input anywhere on the page, by design. For HMAC tokens use the
JWT HS256 Verifier with the shared secret; for RSA-signed tokens use the
JWT RS256 Verifier to inspect the structure a public-key verification will consume.
Why does my token produce a JSON parse error?
Each of the first two segments must Base64Url-decode to valid JSON. Common causes: you pasted only part of the token (a line break in the middle of a segment), the token is actually plain Base64 rather than a JWT, or a segment was altered so its bytes no longer form JSON. Check that the pasted string has exactly the header.payload.signature shape.Is it safe to paste a real production token?
The decode runs entirely in your browser — no network request is made, nothing is stored, and closing the tab clears everything. The habit worth keeping is scoping what you paste: a long-lived token for a production system deserves more caution than a short-lived test token, and the safest practice anywhere is to paste tokens that are already expired or minted specifically for testing.What does it do with an alg:none token?
It decodes normally and reports (unsigned), because such a token genuinely carries no signature segment — the header says alg":"none" and the tool shows you that honestly. Whether that is a problem is context: most JWT libraries refuse alg:none by default precisely because accepting unsigned tokens historically caused serious vulnerabilities, so finding one in the wild is worth a raised eyebrow, and a server that accepts one deserves a security review.My token has five segments — why won't it decode?
Five segments is the compact JWE form: an encrypted JWT whose payload is ciphertext meant to be unreadable without the recipient's key. This tool handles the three-segment JWS form, where header and payload are readable by design. A five-segment token is not broken — it is a different standard (encryption rather than signing) doing a different job, and decryption, not decoding, is the intended way in.Related Tools
JWT Validator checks structure and temporal claims — three segments, parseable JSON,
exp and
nbf against the clock, presence of
iss and
sub.
JWT Generator mints HS256-signed test tokens you can safely paste anywhere.
JWT Expiry Checker gives the precise time remaining on an
exp claim.
Session Token Decoder is the best-effort reader for tokens that may not be JWTs at all. And
JWT HS256 Verifier is the step this tool stops short of: proving the signature.