JWT Parser
v1.0.0Decode JWT tokens, display header and payload, check expiration, show structured claims, and copy decoded data.
JWT Token
JWTs carry signed (or MAC’d) JSON claims in a compact wire format. WMCoder decodes header and payload so you can debug tokens—verification still belongs in your backend.
Read the full guide →Frequently Asked Questions
- What is the structure of a JWT?
- A compact JWT has three Base64url-encoded segments separated by dots: header.payload.signature. The header describes the algorithm and type; the payload holds claims (JSON); the signature (or MAC) proves integrity to anyone with the verification key or secret.
- How is a JWT different from a server session?
- Sessions store state on the server and send an opaque cookie reference. JWTs embed claims in the token itself. That enables horizontal scaling without shared session storage but pushes revocation, size, and trust boundaries into application design.
- What does token expiry (exp) mean?
- exp is a NumericDate claim: after that instant, validators should reject the token. Clock skew between issuers and verifiers requires a small tolerance. Short-lived access tokens plus refresh flows reduce exposure when a token leaks.
- What are common JWT security risks?
- Weak or missing verification, trusting claims without signature check, algorithm confusion (RS256 vs HS256), huge tokens, and putting sensitive PII in the payload (it is only Base64url, not encrypted). Always verify alg against an allowlist and use libraries correctly.
- What is the alg:none attack?
- Attackers set header alg to none and strip the signature; vulnerable servers accept unsigned tokens. Modern libraries reject none for verification, but custom parsers have reintroduced this bug. Never branch verification logic on unauthenticated header content.