JWT Decoder

A JSON Web Token is dot-separated Base64URL segments: header, payload, and signature. The header names the signing algorithm and token type. The payload carries claims—statements about the subject, issuer, audience, expiration, and custom fields.

The signature proves integrity and authenticity when validators know the secret or public key. Decoding reveals JSON content anyone with the token string can read; JWTs are signed, not encrypted, unless you use nested JWE formats this tool may not cover.

Never treat payload contents as secret just because strings look opaque. Client-side storage of JWTs exposes claims to XSS; put only non-sensitive data in payloads when possible.

Three-segment compact serialization is the common case; nested JWTs as claims are advanced patterns this decoder may not expand automatically.

Token size affects HTTP header limits— enormous custom claims break proxies before signature validation ever runs.

sub identifies the subject user or service account. iss names the issuer authority. aud lists intended recipients. exp and nbf bound validity windows in Unix seconds—decoder tools convert these to local time to spot expired tokens quickly.

iat records issuance time. jti provides a unique token id for revocation lists. Custom claims appear as additional JSON keys—roles, permissions, tenant ids—depending on your authorization server.

Algorithm header alg must match what your verifier expects. Tokens declaring none or unexpected algorithms should be rejected in production validators even if decoding succeeds here.

• Debug 401 responses by checking exp against clock skew
• Confirm OAuth scopes landed in access token claims
• Compare iss and aud against expected provider values
• Inspect role arrays before blaming API gateway rules

Decoding parses Base64URL and JSON without cryptographic checks. A attacker can forge base64 segments; only signature verification with the correct key proves the issuer actually signed the token.

Use this page for troubleshooting structure and claim typos during development. Production services must validate signatures, expiration, issuer, audience, and algorithm allowlists in code.

If a token fails API validation but looks fine decoded, suspect clock skew on exp, wrong signing key rotation, or audience mismatch—not JSON formatting.

Paste production tokens only on trusted machines. Decoding locally avoids cloud jwt.io uploads but the string still appears in your browser memory—close the tab when finished.

Redact tokens before screenshots. Claims often include emails, internal ids, and session metadata you do not want in ticket attachments.

Bearer prefixes in Authorization headers are stripped automatically when pasted—paste either the raw JWT or the full header value.

Capture token from network tab or CLI, decode here, verify exp and custom claims, then compare with authorization server documentation. If claims are wrong, fix issuer configuration; if claims are right, trace gateway or resource server validation logic.

For opaque refresh tokens that are not JWTs, this tool cannot help—those are random strings validated server-side against a database.

Single sign-on flows issue short-lived access tokens and longer refresh tokens. Decode access tokens at the API gateway for quick rejection; validate refresh tokens only at the token endpoint with stricter storage.

Multi-tenant SaaS products embed tenant_id claims—decode sample tokens from each tenant after onboarding to verify provisioning scripts did not swap audiences between staging and production issuers.

Mobile apps bundling JWTs in deep links leak claims through referrer logs and browser history. Prefer one-time codes exchanged server-side rather than long JWT strings in URLs.

Clock skew between containers in Kubernetes causes intermittent exp failures. Decode failing tokens, compare exp with UTC on each pod, and synchronize NTP before lengthening token lifetimes as a band-aid.

Libraries in Go, Java, and Python validate variant bits on parse—malformed strings fail fast at API boundaries when QA pastes manually edited tokens.

OIDC id_tokens are JWTs; access tokens may be opaque depending on provider. Confirm token type before assuming decode will reveal JSON.

Custom claims nested objects decode as JSON trees—flatten mentally when comparing to flat key expectations in legacy authorization middleware.

Refresh token rotation policies invalidate old refresh tokens after use—decode access tokens only for quick UI decisions, never store refresh strings in frontend localStorage.

Federated identity providers may embed group memberships as array claims—confirm array versus comma-string format before writing authorization rules.

Machine-to-machine tokens often omit profile claims present in user tokens—decode service tokens separately rather than assuming identical payload shapes.

Security reviews paste decoded tokens into tickets—redact sub and email fields when attachments leave the engineering trust boundary.

Algorithm confusion attacks target validators accepting multiple algs—decode header alg first when investigating suspicious tokens.

Padding and base64url differences break decode on tokens copied from chat apps that wrap lines—paste single-line tokens when possible.