JWT Parser
JWT parser for the browser. Parse the header, payload, and signature of any JWT without sending it anywhere. Decoded JSON is pretty-printed; timestamp claims can be shown in ISO format.
JWT in, JSON out
A JWT is three Base64URL-encoded parts joined by dots: header, payload, signature. Decoding reveals the JSON header and claims.
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signed_value
{
"header": { "alg": "HS256" },
"payload": { "sub": "123" }
}What you'll use this for
JWTs (JSON Web Tokens) carry identity, claims, and metadata between services — decoding them is the first step in debugging auth.
API debugging
Inspect what claims your auth provider issued.
Identity audit
Verify the sub, aud, iss claims match expectations.
Expiry checks
Decode exp and iat to see when the token expires.
Security review
Check the alg header — never trust none.
How to decode a JWT
Paste your JWT
The full three-part token.
Pick format
Pretty / compact / combined.
Inspect
Header, payload, signature shown separately.
Copy or download
Copy to clipboard or save the decoded JSON.
Frequently asked questions
No. Verification needs the signing key, which we don't ask for. Use a server-side library to verify.
No. All decoding happens locally in the browser.
Yes.
JWT (RFC 7519) is a compact, URL-safe token format. It uses Base64URL so the token is safe in headers / query strings.
The token is unsigned — any actor can forge it. This decoder flags it as a warning.
About JWT decoding
A JSON Web Token (RFC 7519) is a compact, URL-safe token format with three dot-separated parts: header.payload.signature. Each part is Base64URL-encoded so the token is safe in HTTP headers, cookies, and query strings.
The three parts
- Header — a JSON object describing the algorithm (
alg) and token type (typ). - Payload — a JSON object with claims like
sub,iss,aud,iat,exp. - Signature — bytes that prove the header + payload weren't tampered with, computed with the signing key.
Decode is not verify
- Decoding only reverses the Base64URL — no key is needed and no trust is implied.
- Verification requires the issuer's signing key (HMAC secret or public key) and must happen server-side.
- If the
algheader isnone, the token is unsigned and forgery is trivial — never accept it.
Why Base64URL
- Base64URL (RFC 4648 §5) replaces
+with-and/with_, and usually drops padding. - This makes the token safe to embed in URLs, file names, and HTTP headers without escaping.