Encoders & Utilities

JWT Decoder

Decode JWT header and payload safely in-browser.

JWT token Paste a JWT — we will split it into header, payload, and signature.

About this tool

A JSON Web Token (RFC 7519) is three Base64url-encoded segments joined by dots: header, payload, and signature. JWT Decoder splits the token, decodes the first two segments to JSON, formats them, and computes the time-related claims (iat, exp, nbf) as human-readable timestamps. Standard registered claims (iss, sub, aud, jti) are labelled with their meaning. Decoding runs entirely in your browser — your token never leaves the page.

The header tells you the signing algorithm (alg: HS256, RS256, ES256, etc.) and the optional kid (key ID). The payload contains the application claims — user ID, roles, expiry. The signature is shown as a Base64 blob; we deliberately do not verify it on this page because verifying requires the issuer's secret or public key, which should never be pasted into a third-party tool. The token is treated as data-only.

When to use this tool

Reading a token from your own service. Inspect what claims you actually emit — quickly spot missing fields, wrong audiences, or surprising defaults.
Debugging "401 Unauthorized" responses. Check expiry, issuer, audience, and scope against what the server expects.
Verifying a third-party integration. When an OAuth provider hands you an ID token, decode the payload to see which user claims they bundle.
Spotting algorithm confusion. If alg is none or unexpectedly differs between tokens, your auth library is likely misconfigured.

Why we do not validate signatures

JWT signature verification requires the secret (for HMAC algorithms) or the issuer's public key (for RSA/ECDSA). Pasting either of those into a web tool is a security mistake — the secret would compromise every token issued; the public key, while less sensitive, can still be private. The decoder confirms structure and reveals claims; for real verification, use the SDK that ships with your auth library (jsonwebtoken, pyjwt, jose) inside your own code.

Frequently asked questions

Is it safe to paste my JWT here?

Decoding happens entirely in JavaScript in your browser — no network call is made, no logging happens server-side. That said, JWTs in production should be treated as credentials: do not paste a long-lived token from a service you do not control into any third-party tool, including ours. For dev/staging tokens or expired tokens, decoding here is fine.

Why is the signature shown but not verified?

Because verification requires the signing key, and pasting a signing key into a web tool would be a serious mistake. The signature is displayed as Base64 so you can see it exists and has the right length for the algorithm, but actually validating it against an HMAC secret (HS256) or a public key (RS256/ES256) belongs inside your application, not in a browser tool.

What does "alg: none" mean?

An unsigned JWT. The header explicitly says no algorithm was applied, so the signature segment is empty. alg: none exists in the spec but should never appear in production — it is the root cause of the famous "JWT none-algorithm" vulnerability where a library accepts none as valid. If you see it in a real token from a real service, that is a serious bug.

What is the difference between exp, iat, and nbf?

iat (issued-at) is when the token was created. nbf (not-before) is the earliest time the token may be used — usually equal to iat but can be in the future for delayed activation. exp (expiration) is when the token stops being valid. All three are Unix timestamps in seconds. A well-behaved verifier checks nbf ≤ now ≤ exp on every request.