JWT Decoder & Verifier
Decode JSON Web Tokens and verify HS/RS/ES/PS signatures — fully in your browser
—
—
What Is a JWT Decoder?
A JWT (JSON Web Token) is a three-part token — header, payload, signature — used for authentication and authorization in modern web apps. The payload looks like random text until you decode it, which is exactly what this tool does. It turns the header and payload into readable, pretty-printed JSON, explains registered claims such as exp, nbf, and iat in plain language with real dates, and shows whether the token is expired, active, or not yet valid. It can also verify signatures: HS256/384/512 with a shared secret, and RS/PS/ES with a PEM public key, all using Web Crypto inside the browser. For developers debugging auth flows, this replaces the habit of pasting production tokens into a third-party website.
What this tool can do
- 📖 Decode header and payload into pretty-printed JSON
- 🏷️ Human-readable explanations for registered claims
- ⏳ exp, nbf, and iat shown as exact dates plus relative time
- ✅ Signature verification for HS256/384/512 with a secret
- 🔏 Signature verification for RS/PS/ES with a PEM public key
- 🚦 Expired, active, or not-yet-valid status badge
- ⚠️ Warning when the alg header is none, meaning an unsecured token
When you will use it
- Debugging a 401 error in your login flow
- Finding out why a token suddenly stopped working
- Verifying a token from a third-party identity provider before trusting it
- Inspecting the claims inside a refresh token
Privacy: tokens and keys are processed entirely in your browser and never uploaded, so pasting real production credentials is safe.
What the three segments actually are
A JWT is three base64url segments joined by dots:
- header names the algorithm; payload carries the claims; signature binds both under a secret or key.
- Nothing in header/payload is encrypted — anyone holding the token reads every claim. That is by design; JWT is a signed container, not a safe.
- Verification needs the signing key and happens on your server; this page decodes locally so you can inspect claims without pasting tokens anywhere remote.
Decoding is not verifying
Claims become real dates
Header and payload print as readable JSON while registered claims like exp, nbf, and iat turn into actual dates, with a clear verdict of expired, active, or not yet valid.
HS, RS, PS, and ES verification
Verify HS256/384/512 against a shared secret in plain or base64 form, and RS, PS, or ES tokens against a PEM public key, using Web Crypto inside the page.
Malformed tokens explained
Structural problems are reported precisely — missing dot, invalid header, unreadable payload — and tokens claiming the none algorithm are flagged instead of trusted.
Frequently asked questions
Is my token sent to a server?⌄
No. Decoding and signature verification happen entirely in your browser using the Web Crypto API. Your token, secret and keys never leave your device, so it is safe to inspect production tokens.
Which signature algorithms can you verify?⌄
HS256/384/512 with a shared secret (UTF-8 or base64url), and the asymmetric families RS256/384/512, PS256/384/512 and ES256/384/512 by pasting the PEM public key. For asymmetric tokens you only need the public key, never the private key.
A JWT is not encrypted — what does that mean?⌄
A standard JWT is only base64url-encoded and signed, not encrypted, so anyone can read its payload. Never put secrets in a JWT. The signature only proves the token was not tampered with by someone without the key.
It says signature invalid — is the token forged?⌄
Usually one of three boring causes: the token was signed by a different environment’s secret; the issuer rotates keys and yours is stale; or the algorithm in the header does not match what your verifier expects (the infamous alg=none trick). Decode the header here first, then compare against the key your backend actually uses.