JWT decoder.

A JWT (JSON Web Token, RFC 7519) in its usual signed form is three Base64URL strings joined by dots: header.payload.signature. The header is a JSON object that names the signing algorithm (alg) and often the token type (typ) and a key ID (kid). The payload is a JSON object of claims about the subject. The signature is binary data, also Base64URL-encoded.

Decoding is mechanical. Split the token on the dots, convert each of the first two parts from Base64URL (RFC 4648, section 5) to bytes, read the bytes as UTF-8 and parse the JSON. This tool does exactly that in your browser. It accepts a raw token or an Authorization header value starting with Bearer, colour-codes the three parts, pretty-prints the header and payload, and turns the time claims into dates. You can do the same by hand with the Base64 decoder in URL-safe mode.

In application code, avoid hand-rolled decoding for anything security-related. Maintained libraries, such as jose for JavaScript, PyJWT for Python or the JWT support built into your web framework, decode and verify in one call and reject tokens that fail any check.

Anyone can read a JWT, and anyone can create one with any claims they like. What makes a token trustworthy is its signature, checked on the server with the issuer's key. Never authorise a request because a decoded payload says role is admin.

With HS256 the issuer and the verifier share one secret (HMAC with SHA-256). With RS256, ES256 or EdDSA the issuer signs with a private key and anyone can verify with the public key, which identity providers usually publish as a JWKS (JSON Web Key Set) endpoint; the kid header tells you which key to use.

Good verification follows RFC 8725, the JWT best current practice: allow only the algorithms you expect, reject alg: none, never let the token's own header choose between HMAC and public-key verification (the classic algorithm-confusion attack), and check iss, aud and exp as well as the signature. Use a maintained library for your language rather than writing this yourself.

RFC 7519 registers seven standard claims: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (a unique token ID). All are optional, but most APIs require at least exp.

The time claims are NumericDates: whole seconds since 1 January 1970 UTC, not milliseconds. A token is expired once the current time is at or after exp, and not yet valid before nbf. The specification allows a small leeway, usually no more than a few minutes, to absorb clock differences between servers.

This decoder shows exp, iat, nbf and the OpenID Connect auth_time claim as dates in your local time zone with a relative hint such as "in 2 hours", and labels the token active, expired or not yet valid against your device clock. To convert other epoch values, use the Unix timestamp converter.

"jwt malformed" or a decoding error usually means the value is not a complete token: it was truncated, still wrapped in quotes, URL-encoded, or copied with a line break. This tool reports when a value has the wrong number of parts, when a part contains characters outside the Base64URL alphabet, or when a part decodes but is not a JSON object.

"invalid signature" means the token was changed or is being checked with the wrong key or algorithm. Common causes are mixing up environments, a rotated key that the verifier has not fetched yet, or a secret with stray whitespace.

"jwt expired" means exp has passed. If a freshly issued token is already expired or not yet valid, compare server clocks. If the exp date decodes to tens of thousands of years in the future, the issuer wrote milliseconds instead of seconds. An audience or issuer mismatch means the token was minted for a different API or tenant.

A session cookie holds an opaque ID and the server looks the session up on each request, so revoking access is instant. A JWT carries its claims with it, so any service holding the key can check it without a database lookup. The trade-off is revocation: a stolen JWT stays valid until it expires, which is why access tokens are usually short-lived and paired with refresh tokens.

In browsers, tokens in localStorage can be read by any script that runs on the page, so a cross-site scripting bug exposes them. An HttpOnly, Secure, SameSite cookie keeps the token away from JavaScript. Our guide to sessions, JWTs and passkeys compares the options in depth.

Most JWTs are JWS tokens: signed but readable. A JWE (RFC 7516) is encrypted and has five parts instead of three, so its payload cannot be read without the decryption key. This decoder recognises the five-part shape and tells you rather than showing garbage.

In OAuth and OpenID Connect, the ID token is always a JWT meant for the client application. Access tokens may be JWTs (RFC 9068 defines a profile for that) or opaque strings, and they are meant for the API. If a provider documents its access tokens as opaque, do not build client code that depends on decoding them, because the format can change.