JWT Decoder & Verifier
Decode, build, and verify JWT tokens — entirely client-side (HS256).
Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. TOOLGRID measures tool usage, not the content you enter.
- No TOOLGRID input upload
- No account
- Review before copy
Loading tool…
What this tool does
Free JWT decoder, builder, and HS256 signature verifier. Inspect header and payload claims, sign new tokens, and validate signatures locally. Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. Browser-local processing avoids a TOOLGRID upload path, but it is not a blanket security guarantee.
Decode, build, and verify JWTs in one place: paste a token to inspect its header and payload, generate a signed HS256 token from a JSON payload, or verify any token's signature against a shared secret.
Decoding and verifying are different operations — decoding only Base64url-decodes the parts (useful for inspection, never proves authenticity), while verifying recomputes the HMAC signature with your secret. Most security incidents come from confusing the two; this tool keeps them in separate tabs so you cannot mix them up.
JWT work uses the browser's Web Crypto API. Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. Browser-local processing avoids a TOOLGRID upload path, but it is not a blanket security guarantee.
Where this tool earns its place
Paste a JWT from your app's local storage or authorization header to inspect the user ID, roles, and expiry without writing code.
When a user reports they can't access a resource, decode their JWT to check if their role claim or expiry is the cause.
Confirm that your auth server is issuing tokens with the correct claims before writing application code that depends on them.
What to check before relying on the result
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
Open a nearby browser tool when you need to validate, convert, or reuse the result.
How to use
01Use Cases
Paste a JWT from your app's local storage or authorization header to inspect the user ID, roles, and expiry without writing code.
When a user reports they can't access a resource, decode their JWT to check if their role claim or expiry is the cause.
Confirm that your auth server is issuing tokens with the correct claims before writing application code that depends on them.
Decode a JWT's payload to read the exp (expiry) timestamp and verify whether a token is still valid.
Tips & Tricks
- 01JWTs are not encrypted — treat them as public
A JWT payload is only Base64url-encoded, not encrypted. Anyone who has the token can decode and read its claims. Never put sensitive data in the payload.
- 02The exp claim is a Unix timestamp
The exp field contains seconds since Jan 1 1970 UTC. Use the Timestamp Converter tool to convert it to a human-readable date.
- 03Decoding is not verification
Decoding only Base64url-decodes the header and payload — it tells you nothing about whether the token is authentic. To prove a token was issued by your auth server, run signature verification on the Verify tab with the shared secret (for HS256) or have your server check it with the public key (for RS256/ES256).
- 04Three parts separated by dots
A JWT looks like xxxxx.yyyyy.zzzzz. The first part is the header (algorithm), the second is the payload (claims), the third is the signature.
- 05Beware of the alg: none attack
If a server accepts tokens with header alg: none, anyone can forge a token by setting alg: none and omitting the signature. Your server should reject the none algorithm explicitly — never decide trust based on the header's alg value alone.
FAQ
02What is the difference between decoding and verifying a JWT?
Decoding only Base64url-decodes the header and payload — it works on any well-formed token, including forged or tampered ones. Verifying recomputes the HMAC (HS256) or signature check using a secret or public key and confirms the token was actually issued by your auth server. Use the Decode tab for inspection; use the Verify tab to prove authenticity.
Can this tool verify the JWT signature?
Yes — open the Verify tab, paste the token, and provide the shared HS256 secret. The tool recomputes the HMAC-SHA256 signature in your browser using the Web Crypto API and returns valid or invalid. For RS256 or ES256 (asymmetric algorithms), verification must happen on the server with the corresponding public key.
Is my JWT or secret sent to a server?
Decoding, signing, and verification use the browser's Web Crypto API. Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. Browser-local processing avoids a TOOLGRID upload path, but it is not a blanket security guarantee.
Why does my decoded payload show numbers instead of dates?
JWT timestamps (iat, exp, nbf) are Unix timestamps — seconds since January 1, 1970 UTC. The decoder surfaces the parsed expiry above the JSON, and you can paste the raw number into the Timestamp Converter tool to read other claims.
What is the alg: none vulnerability?
Some JWT libraries trust the header's alg field to decide which algorithm to verify with. If your server accepts alg: none, an attacker can submit a forged token with no signature and have it accepted. Always pin the expected algorithm on the server side and reject none explicitly.
What's the difference between the header and payload?
The header contains the token type and signing algorithm (alg, typ). The payload contains the claims — standard fields like iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at), nbf (not before), plus any custom data your app embeds.
Can I decode a JWT that's been modified?
Yes — any valid Base64url string decodes. That's exactly why decoding alone proves nothing. The signature is what binds the header and payload to the issuer; any change to either invalidates the signature on verify.
Should I use HS256 or RS256?
Use HS256 when the issuer and verifier share one trusted secret (single backend). Use RS256 (or ES256) when verifiers should not be able to issue tokens — the private key signs, the public key verifies. This tool covers HS256 fully; RS256 tokens decode but verification needs server-side public-key checks.