Tool guide
About JWT Decoder & Parser
A JWT parser decodes the Header and Payload of a JSON Web Token so you can inspect alg, typ, signature status, and common claims such as iss, sub, aud, iat, nbf, and exp.
This tool parses tokens locally in the browser and can re-sign edited Header/Payload data with a local HMAC secret. The token is not uploaded to wetool.site.
How to use the JWT Parser
- Paste a complete JWT in header.payload.signature format.
- Click Decode to inspect the Header, Payload, and common claim summary.
- Check exp, nbf, and iat values; they are usually epoch seconds.
- For HMAC test tokens, enter a secret to re-sign edited Header/Payload data locally in the browser.
When you would use it
- Debug an auth session by checking whether a token is expired or not yet valid.
- Confirm alg, typ, iss, aud, and sub match the API gateway or backend contract.
- Pretty-print the payload JSON to find scope, role, tenant_id, or other app-specific fields.
- Edit a development token claim and re-sign it locally with a known HMAC secret.
JWT structure, claims, and signature limits
A JWT usually has three Base64URL parts: Header, Payload, and Signature. Decoding Header/Payload does not require a secret, but trusting the token requires signature verification with the right key.
- Header: usually contains alg and typ, describing the signing algorithm and token type.
- Payload: contains claims such as iss, sub, aud, iat, nbf, exp, and app-specific fields.
- Signature: protects Header/Payload from tampering; decoding a token does not prove the signature is valid.
- Time claims: iat, nbf, and exp are usually Unix seconds, not milliseconds.
JWT Parser FAQ
- Is decoding a JWT the same as verifying it?
- No. Decoding only reads Header and Payload. Verification requires checking the signature with the correct secret or public key.
- Why can I read the payload without a password?
- JWT Header and Payload are Base64URL encoded, not encrypted. Do not store secrets in a normal JWT payload.
- What are exp, iat, and nbf?
- exp is expiration time, iat is issued-at time, and nbf is not-before time. They are commonly stored as Unix seconds.
- Will a token still work after I edit the Payload?
- Usually not unless it is re-signed. This tool can re-sign HMAC test tokens locally when you enter the secret.
- Is my JWT uploaded?
- No. Decoding, editing, and HMAC re-signing run locally in the browser and the token is not uploaded to wetool.site.
JWT vs session cookies
A session usually stores state on the server and gives the browser a session id. A JWT carries claims inside the token, which helps across services but makes expiration, signing keys, and payload contents more important.
JWT signature verification and alg checklist
A JWT that can be decoded is not automatically trustworthy. Real verification must pin the algorithm, key source, issuer, audience, and signature policy.
- Do not choose the verification algorithm from the token alg header alone; servers should use a configured allowlist.
- Treat alg=none, HS256/RS256 confusion, or kid values that point to external locations as high-risk configurations.
- This tool is useful for inspection and HMAC test tokens, but production verification belongs in the backend or auth gateway.
exp, nbf, and iat time debugging
JWT time claims are usually Unix seconds. When expiration looks wrong, check seconds vs milliseconds, clock skew, and timezone display first.
- If exp is earlier than the current epoch seconds, the token is expired; if nbf is later than now, it is not active yet.
- Interpreting 13-digit milliseconds as seconds produces a far-future date; interpreting 10-digit seconds as milliseconds lands near 1970.
- Servers should keep NTP in sync and allow small clock skew, but long grace periods should not hide configuration mistakes.