/jwt

JWT Decoder - Inspect Header & Payload Offline

Decode JSON Web Tokens (JWT) locally to inspect claims, headers, and expiry timestamps.

How it works

A JWT consists of three Base64URL parts: header, payload and signature. This tool decodes the first two and renders timestamps like iat and exp in readable form. The signature is not verified, that requires a secret key. Everything happens locally in your browser.

About this tool

A JSON Web Token (JWT) is a compact, signed text format for exchanging claims between parties, typically used for authentication and authorization in modern web APIs. A JWT has three parts separated by dots: header, payload and signature. This tool decodes JWTs so you can see what is in the header and payload, verifies the signature against a secret or public key, and helps you understand fields like `exp`, `iss`, `aud` and `sub`. Everything runs locally, your token never leaves the browser, which is essential when debugging with real access tokens.

How to use it

  1. Paste a JWT (three base64url strings separated by dots) into the input field.
  2. Header and payload are decoded automatically and shown as formatted JSON.
  3. Check `exp` (expiry) and `iat` (issued at), the tool converts Unix timestamps into readable dates.
  4. Optional: paste your secret (HS256) or public key (RS256/ES256) to verify the signature.

Examples

Structure
InputeyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiT2xhIn0.5xB4pk9L-...
Three base64url parts: header ({"alg":"HS256"}), payload ({"sub":"123","name":"Ola"}) and HMAC-SHA256 signature.
Typical payload
Input{ "sub": "user-42", "iss": "https://auth.example.com", "aud": "api.example.com", "exp": 1735689600, "iat": 1735686000 }
`sub` = the user’s ID, `iss` = issuer, `aud` = intended audience, `exp` = expiry, `iat` = issued-at time (all as Unix timestamps).

Common use cases

  • Debugging API calls that fail with 401/403 by inspecting the token itself.
  • Verifying that your client sets the right `aud` and `iss` in tokens it sends.
  • Checking whether a token is expired without having to try the API call.
  • Seeing what roles or scopes a user actually has, based on the claims.
  • Verifying the signature from an identity provider (Auth0, Okta, Azure AD, Google) against their JWKS.
  • Teaching new developers how a JWT is structured.

Frequently asked questions

Is the payload encrypted?
No. A signed JWT is only base64url encoded, not encrypted. Anyone with the token can read the header and payload. Never put sensitive data (passwords, national IDs, credit cards) into a JWT.
What is the difference between HS256 and RS256?
HS256 is symmetric (HMAC-SHA-256), the same secret signs and verifies. RS256 is asymmetric (RSA + SHA-256), the private key signs, the public key verifies. RS256 (or ES256) is preferred when signer and verifier should not share secrets.
Does the tool send my token anywhere?
No. Everything happens in the browser using SubtleCrypto, neither your token nor your key ever leaves the page. Safe to use with real production tokens.
What does "alg: none" mean?
"none" means the token is not signed. This is a well-known JWT weakness, servers that blindly accept `alg: none` can be tricked into accepting anything. Your verification library should always have an allow-list of algorithms.

Technical background

JWT is defined in RFC 7519, with the underlying signature formats in JWS (RFC 7515) and optional encryption in JWE (RFC 7516). Common algorithms are HS256/384/512 (HMAC), RS256/384/512 (RSA-PKCS1), ES256/384/512 (ECDSA) and PS256/384/512 (RSA-PSS). The signature covers `header.payload` after base64url encoding, signed with the chosen algorithm. When verifying, you must check both the signature AND the `exp`, `nbf` and `iss`/`aud` claims, otherwise a valid-signed token could still be forged or expired.