JWT Decoder
Paste a JSON Web Token to decode its header and payload, read the claims — exp, iat, iss, aud — in plain English, and catch the common security problems. You can also verify the signature (HS256, RS256, ES256 and more) right here. Everything runs in your browser with the Web Crypto API — your token is never sent to any server.
Your token is decoded and verified entirely in your browser — it is never sent to any server. No network request is made. As a rule, never paste a production JWT into a website you do not trust: a JWT is signed, not encrypted, so anyone who captures it can read every claim and, if it is still valid, replay it.
What this tool is
- A free, in-browser JWT decoder: paste a JSON Web Token and get its header, payload and signature split into three panels, with the JSON pretty-printed.
- Standard claims are rendered human-readable — exp, iat and nbf show the absolute UTC time and a relative phrase ("expired 3h ago" / "expires in 20m"), alongside alg, typ, kid, iss, aud and sub.
- Security checks flag the common mistakes: alg "none", an expired token, a missing exp, and the shared-secret risk of the HS* family.
- Optional signature verification runs entirely in your browser via the Web Crypto API — HMAC for HS256/384/512 with a secret, and RSA/ECDSA for RS*/PS*/ES* with a PEM public key.
- Nothing you paste — token, secret or key — is ever sent to a server. There are no network requests.
What is a JWT and how does it work?
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (alg) and token type; the payload carries the claims (who the token is about, who issued it, when it expires); and the signature is the result of signing the header.payload string with a key.
The critical thing to understand: a standard JWT is signed, not encrypted. base64url is just an encoding, not a cipher, so the header and payload are readable by anyone who holds the token — this decoder simply reverses that encoding. The signature does not hide anything; it only lets a verifier confirm the token was not altered and was produced by whoever holds the signing key. So never place secrets in a payload, and treat any token you can see as fully exposed.
JWT signing algorithms
The header's alg says how the token was signed. The common families:
| alg | Scheme | Notes |
|---|---|---|
| HS256 / HS384 / HS512 | HMAC with SHA-256/384/512 (symmetric) | One shared secret signs and verifies. Simple, but the verifier holds the signing key — a weak secret is forgeable. |
| RS256 / RS384 / RS512 | RSASSA-PKCS1-v1.5 (asymmetric) | A private key signs, a public key verifies. The most common choice for OIDC ID tokens. |
| PS256 / PS384 / PS512 | RSASSA-PSS (asymmetric) | RSA with the modern PSS padding scheme; verified the same way, with a public key. |
| ES256 / ES384 / ES512 | ECDSA on P-256/384/521 (asymmetric) | Elliptic-curve signatures — smaller keys and tokens than RSA for the same strength. |
| none | No signature | An unsigned token. A verifier that accepts "none" trusts anything — a classic bypass. Always reject it. |
Common JWT vulnerabilities
Most JWT breaks come from the verifier trusting something the attacker controls. The checks this decoder runs map to these:
A token whose header says {"alg":"none"} carries no signature. A verifier that honours the header-declared algorithm will accept a token anyone can mint. The fix is to decide the expected algorithm server-side and reject anything else — never let the token choose.
HS256 security rests entirely on the secret. A short or dictionary-word secret can be brute-forced offline from a single captured token, after which an attacker forges valid tokens at will. Use a long, random secret (or an asymmetric algorithm).
Without an exp claim a token is valid forever, so a single leak is a standing bypass. A correct verifier checks exp and nbf against the clock and confirms aud and iss — a valid signature alone is not enough.
If a service verifies with a key but lets the header pick the algorithm, an attacker switches RS256 to HS256 and signs with the RSA public key (which they have) as the HMAC secret. Pin one algorithm per key out of band.
Want to perform these attacks against real tokens and then pick the server-side fix? The JWT Attack & Defense Lab is a graded, hands-on trainer built on the same Web Crypto primitives.
References: JWT (RFC 7519), JWS (RFC 7515) and the JSON Web Algorithms (RFC 7518). This tool is an independent implementation and is not affiliated with any JWT library or vendor.
Frequently asked questions
What is a JWT (JSON Web Token)?
A JWT is a compact, URL-safe way to represent claims between two parties. It has three parts separated by dots: a header, a payload and a signature. The header and payload are JSON objects, base64url-encoded; the signature is produced by signing the header-and-payload string with a key. JWTs are commonly used as access or ID tokens in OAuth 2.0 and OpenID Connect — a server issues one after login, and the client sends it back on each request so the server can trust who is calling without a database lookup.
Is a JWT encrypted? Can anyone read it?
No — a standard JWT (a JWS) is signed, not encrypted. The payload is only base64url-encoded, which is reversible by anyone, so every claim inside is readable by whoever holds the token. The signature protects integrity and origin (it proves the token was not altered and came from the signer), but it does not hide the contents. Never put secrets or sensitive personal data in a JWT payload, and treat a captured token as fully readable. If you need the contents hidden, use JWE (encrypted JWT) instead.
Is this JWT decoder safe to use?
Yes. Decoding and signature verification happen entirely in your browser using JavaScript and the Web Crypto API — the token, any secret and any public key you paste are never transmitted anywhere, and the page makes no network request to process them. That said, as a general habit you should avoid pasting production tokens into any website you do not trust: because a JWT is readable, a malicious site could capture and replay it. For maximum caution with a live token, use the decoder on a token you can afford to expose, or inspect it offline.
What is the difference between decoding and verifying a JWT?
Decoding just base64url-decodes the header and payload so you can read the claims — it needs no key and tells you nothing about whether the token is genuine. Verifying checks the signature with a key: for HS256/384/512 you supply the shared secret and the tool recomputes the HMAC; for RS256/ES256 and similar you supply the signer's public key. A valid signature means the token was produced by someone holding the key and has not been tampered with. Verification still does not check expiry or audience — a complete server-side check verifies the signature and then validates exp, nbf, aud and iss.