This page is the canonical guide to inspecting JSON Web Tokens with DevUtilities’ JWT Decoder. Use the decoder above while you read, or jump to a topic below. Header and payload decoding runs entirely in your browser — tokens are never uploaded for verification or analytics.

JWT Decoder is a client-side inspector for compact JWS tokens (header.payload.signature). It Base64URL-decodes the first two segments, JSON-parses claims, and surfaces alg, typ, exp, nbf, iat, sub, and custom fields for debugging — without treating a successful decode as cryptographic proof.

What you get

• Three-segment split with structured header and payload JSON
• Visibility into registered claims (exp, nbf, iat, iss, aud, sub) and custom claims
• Clear separation between decode (this tool) and signature verification (your backend / JWKS)
• Local-only processing suitable for staging tokens and redacted production samples

Use this decoder when

• You need to see why an API returns 401 despite a “valid-looking” token
• You are comparing claim sets across environments during key rotation
• You want to confirm Base64URL segments before wiring a verifier
• You are teaching or documenting JWT shape without pasting secrets into a third-party site

Do not expect

• HMAC, RSA, or ECDSA signature verification — this tool is decode-only
• Automatic clock skew handling against a trusted NTP source
• JWKS fetch or issuer trust decisions

Decoding proves only that segments are well-formed Base64URL JSON. Verification proves the signature matches a trusted key and that time/audience constraints pass. Confusing the two is a common auth bug.

Decode (this tool)

• Splits on '.' and requires three parts for compact JWS
• Base64URL-decodes header and payload, then JSON.parse
• Shows claims even when the signature is wrong, expired, or alg is none

Verify (your secure backend)

• Checks alg against an allowlist — never trust header.alg blindly
• Validates HMAC/RSA/ECDSA with issuer secret or JWKS public key
• Enforces exp, nbf, iss, aud, and optional jti replay controls

Walk through a typical debug session with the decoder above.

1. Copy the raw JWT only — strip Bearer prefixes, quotes, and trailing newlines from logs.
2. Paste into the input panel; the tool splits header.payload.signature automatically.
3. Read the header: confirm alg and typ match what your issuer is supposed to emit.
4. Read the payload: check sub, roles/scopes, exp, nbf, and any tenant or environment claims.
5. Compare exp and nbf to Math.floor(Date.now()/1000) in UTC if APIs reject the token.
6. If claims look correct but APIs still fail, move to signature verification in your backend — do not assume decode equals trust.
7. Clear the editor (and localStorage if used) after inspecting production-like tokens on shared machines.

Problem: a mobile client receives intermittent 401s. Logs show a JWT that “looks fine” in the network tab, but the API gateway rejects it.

How this tool helps

1. Paste the failing token and confirm three segments decode without structure errors.
2. Check alg — unexpected none, HS256 vs RS256 mismatches, or typ typos often explain gateway rejects.
3. Inspect exp and nbf against UTC; clock skew and timezone bugs are frequent on devices.
4. Compare custom claims (tenant, env, scope) to what the gateway policy expects.
5. Hand the same token to your verifier with the correct JWKS/secret once claims look right.

Outcome: you separate malformed tokens, claim/policy mismatches, and true signature failures before changing client code blindly.

Problem: product asks which claims ship in the access token after a new OIDC mapping. Docs are stale; you need a live sample.

How this tool helps

1. Obtain a non-production access token from the staging authorize flow.
2. Decode and list registered vs custom claims in the payload JSON.
3. Note claim names and types (string vs number for NumericDate fields).
4. Document the claim contract for API authors without sharing the signature secret.

Outcome: a concrete claim inventory for design docs — still remembering the token is not verified here.

Problem: you are rotating signing keys. Some services still mint tokens with the old kid; others already use the new JWKS entry.

How this tool helps

1. Decode tokens from each issuer path and record header.kid and alg.
2. Confirm payload iss/aud still match during the dual-publish window.
3. Flag tokens missing kid or using unexpected alg before cutting over verifiers.
4. After cutover, spot-check that new tokens no longer reference the retired kid.

Outcome: a claim/header checklist for rotation — signature proof still happens in services that hold keys.

alg:none (or accepting arbitrary alg from the header) is a classic JWT attack against misconfigured libraries.

Why it happens

Some early libraries treated alg:none as “unsigned but valid,” or allowed attackers to switch RS256 tokens to HS256 and verify with the public key as an HMAC secret.

Diagnose

Decode the header. If alg is none, empty, or not on your allowlist, treat the token as hostile regardless of a pretty payload.

Fixes

1. Configure verifiers with an explicit algorithm allowlist (e.g. only RS256 or only ES256).
2. Reject tokens whose header.alg is none or missing.
3. Never derive the verify algorithm solely from untrusted header input.
4. Prefer asymmetric algorithms with JWKS rotation for public clients.

This decoder will still show the payload for alg:none tokens — visibility is not endorsement. Reject them in production verifiers.

APIs often return 401 when exp has passed or nbf is still in the future, even though the token decodes cleanly.

Why it happens

NumericDate claims are seconds since Unix epoch. Clients may compare milliseconds, apply local timezone offsets, or ignore clock skew windows.

Diagnose

Decode exp and nbf as JSON numbers. Compare to Math.floor(Date.now()/1000). String exp values or millisecond timestamps are malformed per RFC 7519.

Fixes

1. Normalize comparisons to UTC seconds; allow a small skew (e.g. 30–60s) on both sides if policy permits.
2. Ensure issuers emit NumericDate numbers, not ISO strings.
3. Check device clock sync when only mobile clients fail.
4. Confirm nbf is not set far in the future after a bad deploy.

JWT segments use Base64URL (RFC 4648 §5): - and _ instead of + and /, with padding often omitted.

Why it happens

Pasting standard Base64, adding = padding incorrectly, or mixing alphabets breaks decode. Truncated copy-paste drops the signature segment.

Diagnose

Look for +/ in segments, spaces, Bearer prefixes, or fewer than three dot-separated parts. Valid JWT segments should be URL-safe.

Fixes

1. Strip Bearer and whitespace before paste.
2. Re-copy the full three-part token from the source — do not re-encode with standard Base64 tools unless you convert to Base64URL.
3. When building tokens, use Base64URL without relying on atob/btoa alone for binary safety.

Quick reference for compact JWS shapes and common pitfalls. Decoding success ≠ verification success.

• Treat decode-only output as untrusted until a backend verifies the signature.
• Reject alg:none and unexpected algorithms in production.
• Do not paste long-lived refresh tokens on shared kiosks; clear local state afterward.
• Redact PII in screenshots of decoded payloads before sharing.
• Keep signing secrets and private keys out of browser workflows — use JWKS on the server.

• Document the claim contract (names, types, lifetimes) separately from verification code.
• Prefer short-lived access tokens; put sensitive authorization in server sessions when possible.
• Log kid and iss during incidents — not full tokens — when retention policies allow.
• Use this decoder for shape and claims; use automated tests against a real verifier for security gates.
• During key rotation, dual-publish JWKS and monitor kid distribution before retiring keys.

All Base64URL decoding and JSON parsing run in your browser. Tokens are not sent to a verification endpoint, JWKS proxy, or analytics pipeline from this utility.

• Optional localStorage persistence (if enabled by the workspace) stays on your device origin only.
• Decoded payloads may contain PII — handle output like sensitive logs.
• Clear the editor after debugging production-like tokens.