How do I create a signed JWT?
Enter a JSON payload and a secret key, then this tool builds a {alg, typ:'JWT'} header, base64url-encodes the header and payload, and HMAC-signs them with your chosen algorithm (HS256, HS384 or HS512). The finished token is header.payload.signature. Everything runs in your browser and nothing is uploaded.
How a signed JWT is built
A JSON Web Token is three pieces of base64url text joined by dots. The first piece is the header, a small JSON object that names the signing algorithm. The second is the payload, the JSON object of claims you supply above. The third is the signature, which this tool produces by running an HMAC hash over the first two pieces using your secret key. Change a single character of the header or payload and the signature no longer fits, which is exactly what stops anyone tampering with a token.
The header and payload are only encoded, never encrypted. Anyone holding the token can read both in full, so treat the payload as public: put an identifier, a role or an expiry time in it, but never a password, an API key or card details. Build the token below and paste it into the JWT decoder to see exactly what a recipient can read back.
The signature is the whole point
Decoding a token is easy and proves nothing, because anyone can write any claims they like. What makes a token trustworthy is that the signature can only be produced by a party that knows the secret. When a server receives the token it repeats the same HMAC calculation with its own copy of the secret and checks that the result matches. A wrong secret, or a payload someone edited in transit, produces a different signature and the server rejects the token.
The algorithm you choose changes only the hash used in that step, and with it the length of the signature. HS256 uses SHA-256, HS384 uses SHA-384 and HS512 uses SHA-512. A longer hash gives a longer signature and a token that is slightly bigger on the wire; for most applications HS256 is the sensible default, which is why it is selected above. The two examples below carry an identical payload but produce very different signatures.
HS versus RS, and why this signs locally
The HS family is symmetric: the same secret both signs and verifies, so every party that can check a token could also mint one. That is fine when a single service issues and consumes its own tokens. The RS family (RS256 and friends) is asymmetric instead: a private key signs and a public key verifies, so you can hand out the public key to let others check tokens without ever being able to forge them. This tool signs with HMAC because that is what runs safely in a browser with nothing but a shared secret. If you need RS256 you need a private key, which belongs on a server and never in a web page.
Everything here happens on your device through the built-in WebCrypto API. Your payload and your secret are typed into the page, signed in memory and shown back to you; none of it is uploaded, logged or stored. That makes this a safe way to build test tokens for a development environment, reproduce a token your backend expects, or check that a client handles a given claim set. It is not the place to sign tokens with a real production secret, because a secret pasted into any web page, including this one, should afterwards be treated as one you need to rotate.
This tool signs test tokens; the JWT decoder reads them back. Together they cover both sides of debugging a JWT flow. For the wider picture of what a token is and why decoding is not the same as verifying, the decoder page goes into more depth.
How we work it out
Builds a header {alg, typ:'JWT'}, base64url-encodes the header and the JSON payload (UTF-8 safe), joins them with a dot as the signing input, then signs that with WebCrypto HMAC using the SHA hash matching the algorithm and your secret. The base64url signature is appended to form the three-part token.
Frequently asked questions
Is my payload or secret sent anywhere?
No. The token is built and signed with the WebCrypto API in your browser, so your payload and secret never leave your device. It is still wise to treat any secret you paste into a web page as one to rotate afterwards, and to reserve this tool for test tokens rather than production secrets.
Is the payload encrypted?
No. The payload is only base64url-encoded, which is an encoding, not encryption. Anyone holding the token can read the header and payload in full, so never put passwords, card numbers or other secrets inside it. Only the signature depends on the secret key.
What is the difference between HS256, HS384 and HS512?
They are the same HMAC signing scheme using different SHA hashes: SHA-256, SHA-384 and SHA-512. A larger hash produces a longer signature and a slightly bigger token. HS256 is the common default and is fine for most uses; pick a larger one only if your system requires it.
Can this tool sign RS256 tokens?
No. RS256 and other RS algorithms are asymmetric and need a private key, which belongs on a server and should never be pasted into a web page. This tool signs with the HS family, which uses a single shared secret and runs safely in the browser. Use it for HMAC-signed test tokens.
How do I check the token I made?
Paste it into the JWT decoder to read the header and payload back and confirm the claims and any expiry. Your own backend will verify the signature by repeating the same HMAC with its copy of the secret. If verification fails, the secret or the algorithm usually does not match.