1001Ferramentas
🔏Security

JWT Builder (HS256)

Build a JWT by filling in header, payload and secret. HS256 signature computed in the browser via SubtleCrypto.

Build a test token and watch the signature happen

When debugging an API you almost always need a JWT with specific claims: a different sub, an already-expired exp, one extra field in the payload. Spinning up the backend just to mint a test token is slow. Here you edit the header and payload as JSON, type the secret, and the HS256 token appears assembled and signed in real time, with the three parts color-coded so you can see where one ends and the next begins.

The three parts are base64url, not plain base64: '+' becomes '-', '/' becomes '_' and the '=' padding is dropped, which is why pasting a JWT into a generic base64 decoder often fails. The signature is an HMAC-SHA256 computed over the exact bytes of header.payload. One deliberate gotcha: changing the alg field in the header changes nothing here, the tool always signs with HS256. The same lesson applies to servers: blindly trusting the alg inside a token is a classic vulnerability.

Use a test secret, never a production one, even though the signature is computed by SubtleCrypto right in your browser with nothing sent anywhere. Remember a JWT is signed, not encrypted: anyone can decode the payload without the secret, so keep passwords and sensitive data out of the claims. And the most common bug of all: exp and iat are Unix seconds, not milliseconds; pasting Date.now() without dividing by 1000 produces a token that only expires thousands of years from now.

Frequently asked questions

Why does my server reject the token I built here?
The usual suspects: a secret that differs from the server's (one extra space is enough), exp in milliseconds instead of seconds, or the server expecting a different algorithm such as RS256 while this token is HS256.
I changed alg in the header to RS256. Is the token RS256 now?
No. The header is just text: this tool always signs with HMAC-SHA256. It is a good reminder that a server should never pick its verification algorithm based on what the token itself claims.
Can I see what is inside a JWT without the secret?
Yes: header and payload are plain base64url, anyone can decode them. The secret is only needed to create or verify the signature, meaning it guarantees integrity, not confidentiality.

Read more on this

Related Tools