Build a signed JSON Web Token from a payload and a secret, or paste an existing token to see what is inside it. The tool shows the header and claims, turns the issued-at and expiry times into dates, and checks the signature when you supply the secret. Use it for testing only.
The first part is a small JSON header such as {"alg":"HS256","typ":"JWT"}. The second is the payload, a JSON object of claims. Both are turned into text with base64url, which is ordinary base64 with the plus and slash swapped for a hyphen and an underscore and with the trailing equals signs removed, so the token is safe in a URL or header.
The signature is computed over those two encoded parts exactly as they appear, which is why re-formatting the JSON after signing breaks the token. This tool writes the header and payload in compact form with no spaces, which is what most libraries do and what keeps the token short.
The standard claims are short names: sub for the subject, usually a user id; iss for who issued the token; aud for who it is meant for; iat for the issue time; and exp for the expiry. Your own claims, such as a role or a plan name, can sit beside them. Keep the payload small, because the token travels with every request.
Short lifetimes limit the damage if a token leaks. Many apps issue an access token that lasts minutes and a separate way to get a fresh one, instead of one token that lasts for weeks. Set the lifetime here to match what you are testing, then paste a stale token into the decoder to confirm your app rejects it.
A generated token is handy for calling a protected endpoint from a command line or an API client without going through a login. It also lets you test the unhappy paths: an expired token, a token signed with the wrong secret, and a token with a claim missing.
Remember the limits. A token that decodes cleanly here says nothing about whether your server checks the signature, the expiry and the algorithm the way it should. A classic mistake is accepting whatever algorithm the token header names; always fix the allowed algorithm on the server side.
A JWT is three parts joined by dots: a header naming the signing method, a payload of claims such as the user and the expiry time, and a signature. Each of the first two parts is JSON encoded with URL-safe base64.
For HS256, HS384 and HS512 the signature is an HMAC of the text 'header.payload' using your secret and the SHA-256, SHA-384 or SHA-512 hash. Anyone with the same secret can recompute it, so the server can tell whether the header or payload was changed.
iat is when the token was issued and exp is when it stops being valid, both in seconds since 1970. If you set an issued-at of 1700000000 and a lifetime of 3600 seconds, exp is 1700003600, one hour later.
No. Anyone can read the header and payload. Only a matching signature, checked with the secret, shows the content was not altered. Servers must verify the signature and the expiry before trusting any claim.
It can decode them, but not check their signature. Those methods use public and private key pairs, and this tool handles only the shared-secret HMAC family (HS256, HS384 and HS512).
No. The signing and checking run as code in your browser and nothing is uploaded.
Related: Hash generator, JSON formatter and validator, Hex converter.
Start for free or see all free tools. We.Inc is free to start, with no card needed. AI building is on paid plans from $20 a month.
We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label plans start at $99 a month for 25 client sites, with a 7-day free trial and no per-site fees.