JWT Decoder

About the JWT Decoder

A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe string used to assert claims between two parties, most commonly as a bearer credential after a user signs in to a web or mobile application. A JWT encodes a small JSON object that the server can read to identify a user, their roles, and an expiration, without a database lookup on every request. This decoder lets you inspect the contents of a token — its header, payload, and signature — entirely in your browser, which is exactly what you need when debugging authentication failures.

How it works

A JWT has three base64url-encoded parts joined by dots: header.payload.signature. The header declares the token type (typ) and the signing algorithm (alg, for example HS256 or RS256). The payload carries the claims — standard ones like sub (subject), exp (expiration), iat (issued-at), iss (issuer), and aud (audience), plus any custom claims. The signature is computed by the issuer over the base64url of the header and payload using the algorithm from the header and a secret (HMAC) or private key (RSA/ECDSA).

Base64url is the variant this tool must handle: it replaces + with - and / with _, and omits the = padding, so the token is safe inside URLs and headers. Decoding is just reversing that and parsing JSON — it is reading, not security. The critical distinction: decoding reveals the payload to anyone who has the token (a JWT is signed, not encrypted); only signature verification against the secret or public key proves the token was not tampered with. This tool decodes and reads only — it does not verify signatures, so never trust claims from an unverified token.

Common use cases

• Inspecting a token returned by an OAuth2 or OpenID Connect server
• Debugging an expired exp or wrong aud causing 401 responses
• Auditing which claims and scopes an identity provider actually issued
• Verifying the alg header before implementing server-side verification
• Teaching how the three-part structure maps to header, payload, and signature

Worked example

Given this (unsigned, sample) token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTczNTY4OTYwMCwiZXhwIjoxNzM1Nzc2MDAwfQ.sOmE_s1gN0tBp2xV7l3oFakeSig

Decoding the first segment yields the header:

{ "alg": "HS256", "typ": "JWT" }

And the second segment yields the payload:

{
  "sub": "1234567890",
  "name": "Ada Lovelace",
  "iat": 1735689600,
  "exp": 1735776000
}

Anyone can reproduce this output from the token — that is why a JWT must never contain secrets, and why you must verify the signature before acting on the claims.