$ exec jwt
JWT Decoder
Paste any JSON Web Token to see its header, decoded claims, expiry, issuer, scopes, and an algorithm-safety verdict. Everything runs locally in your browser — the token never leaves your machine.
output will appear here.
$ cat about.md
A JSON Web Token (JWT) is a compact, URL-safe way to transmit signed claims between parties. It is the de-facto identity and authorization token for OpenID Connect, OAuth 2.0, AWS Cognito, Azure AD / Entra, Auth0, Okta, Firebase, and most modern API gateways. Although a JWT looks like opaque gibberish, the first two segments are simply Base64URL-encoded JSON and can be inspected without a key.
This decoder splits the token into its three parts (header, payload, signature), decodes the JSON, then enriches the output with a glossary of every standard claim defined in RFC 7519, OpenID Connect Core, OAuth 2.0, and common provider extensions. It detects the issuer (Google, Auth0, Okta, Cognito, Entra, GitHub Actions OIDC, Keycloak, Apple, Firebase, etc.), identifies the token type (ID, access, refresh, DPoP, logout), summarises the algorithm family and its security posture, and converts every epoch timestamp into both ISO-8601 and a human-readable “in 14 minutes” style.
A JWT decoder does not verify the signature — verification requires the issuer’s public key. This tool is intentionally read-only and runs entirely in your browser, which means you can safely inspect production tokens without leaking them to a third-party server. If you need to verify a token, fetch the issuer’s JWKS endpoint and use a server-side library such as jose, jsonwebtoken, or your platform’s built-in JWT support.
$ ls examples/
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkthcnRoaWNrIFAiLCJpYXQiOjE3MDAwMDAwMDAsImV4cCI6OTk5OTk5OTk5OX0.dGVzdC1zaWduYXR1cmUShows the header, decoded claims, expiry status, and HMAC algorithm verdict.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEiLCJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJpYXQiOjE2MDAwMDAwMDAsImV4cCI6MTYwMDAwMzYwMH0.signatureDetects Google as the issuer and flags the token as EXPIRED.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjMifQ.Marks the algorithm insecure and explains why alg=none is forgery-prone.
$ man --faq
Q.Is my JWT data safe? Do you log tokens?
A.Yes, your data is safe. The decoder is 100% client-side JavaScript — your token is never transmitted, logged, or persisted anywhere. The site is a static export served by GitHub Pages with no backend.
Q.Does this verify the JWT signature?
A.No. Signature verification requires the issuer’s public key (or the shared HMAC secret). This tool only decodes and analyses the header and payload, which is what most debugging and inspection tasks need.
Q.What is the difference between a JWS and a JWE?
A.A JWS (JSON Web Signature) has 3 dot-separated parts and a readable payload. A JWE (JSON Web Encryption) has 5 parts and an encrypted payload — only the protected header can be inspected without the recipient’s key. The decoder handles both cases.
Q.Why is my token marked EXPIRED?
A.The exp claim is in the past. Compare the “expires” line to your local time. If you’re testing, generate a fresh token or set exp far in the future. ID tokens typically live 5–60 minutes; access tokens 15 minutes to 1 hour.
Q.What does it mean when alg=none is flagged insecure?
A.alg=none means the token has no signature, so anyone can forge one. It exists in the spec for testing and should never be accepted by a production verifier. Some libraries had CVEs in the past where attackers exploited this.
Q.Why are some claims labelled “custom / unrecognized”?
A.Issuers may add their own private claims (for example tenant IDs or feature flags). Anything not in the standard glossary is grouped here so you can spot what’s vendor-specific.