Say this plainly up front: this is a client side testing and debugging tool, not a production authentication system. Typing a real production signing secret into any browser based tool, including this one, is not how a production auth token should be minted. Use this jwt generator to understand the structure of a JWT, to build sample tokens for local development, or to hand craft a token for a test suite, and mint real production tokens only from a trusted backend service that never exposes its signing secret to a browser.
Nothing you enter here is transmitted anywhere. The secret, the payload and the resulting token are all generated and signed locally using your browser's built in cryptography, with no network request involved at any point in the process.
What a JWT generator actually assembles
A JSON Web Token has three parts separated by periods: a header describing the signing algorithm, a payload carrying whatever claims you choose, and a signature that proves the first two parts were not altered by anyone who does not know the secret. This jwt generator builds all three from what you provide, then joins them together in the standard three part format.
The header is generated automatically from your chosen algorithm, since it only ever needs to state the algorithm and the token type. The payload is the part you fully control, edited as raw JSON in a text box, which is exactly where the claims that matter for your specific test case, such as a user identifier, an expiry time or a custom role field, get defined.
- Build a sample token for a local development environment without waiting on a real authentication service.
- Generate a specific set of claims, including an expired or malformed one, to test how your backend handles it.
- Understand the exact structure of a JWT by watching the header, payload and signature assemble step by step.
- Never use a production signing secret inside this or any other browser based jwt generator.
Choosing an HMAC hash algorithm
This tool signs using HMAC, which uses the exact same secret for both signing and verifying a token, making it the simplest signing scheme to test with since there is only one secret to manage on both sides. Pick HS256, HS384 or HS512 depending on which algorithm your backend expects to verify against, since a mismatch between the algorithm named in the header and the one actually used to sign the token will make any correct verifier reject it immediately.
A longer hash, such as HS512 over HS256, does not make a weak secret strong. The signature's real security depends entirely on the secret staying unknown to an attacker, not on which specific HMAC variant computes it, so a short or guessable secret remains just as easy to forge regardless of which algorithm you select here.
Editing the payload and understanding common claims
The payload box accepts any valid JSON object, which becomes the token's set of claims once encoded. A handful of claim names carry special meaning by convention, even though this jwt generator does not enforce or validate them: exp for an expiry time, iat for when the token was issued, sub for the subject the token identifies, and both are typically expressed as Unix timestamps in seconds rather than milliseconds.
Because this tool trusts whatever JSON you provide, it is a genuinely useful way to generate jwt token examples with deliberately unusual or invalid claims, such as an expiry time in the past, to confirm your backend's token validation actually rejects them the way you expect, rather than only ever testing against a perfectly well formed token.
RFC 7519's three segments, joined by periods
The header and payload are each serialised to JSON, encoded as UTF-8 bytes, and converted to base64url, the URL safe variant of base64 that JWTs use throughout, since standard base64's plus and slash characters would otherwise need escaping inside a token. Those two segments are joined with a period to form the signing input.
That signing input is then signed using SubtleCrypto.importKey followed by SubtleCrypto.sign with the HMAC algorithm and your chosen hash function, both part of the Web Crypto API built into every modern browser. The resulting signature bytes are base64url encoded and appended as the third segment, producing a hmac sha256 jwt, or its HS384 or HS512 equivalent, that any standard library will verify correctly given the same secret.
| Algorithm | Signature size | Header alg value |
|---|---|---|
| HMAC-SHA256 | 256 bits | HS256 |
| HMAC-SHA384 | 384 bits | HS384 |
| HMAC-SHA512 | 512 bits | HS512 |
How to use this jwt generator
- 1
Choose an HMAC algorithm
Pick HS256, HS384 or HS512 to match whatever your backend or test suite expects to verify against.
- 2
Edit the payload JSON
Adjust the claims in the payload box, such as sub, exp and any custom fields your test needs.
- 3
Enter a secret
Type the shared secret to sign with. Never use a real production signing secret here.
- 4
Generate and copy the token
Press generate to build and sign the token, then copy it for use in a test request or client.
Related tools worth bookmarking
Sources and further reading
- MDN: SubtleCrypto.signThe Web Crypto method this tool uses to compute the HMAC signature for each generated token.developer.mozilla.org
- RFC 7519: JSON Web Token (JWT)The specification defining the header, payload and signature structure this generator assembles.rfc-editor.org
- OWASP Cheat Sheet SeriesPractical guidance on JWT security, including why signing secrets belong on a trusted backend, not in a browser tool.owasp.org
Frequently asked questions
Common questions about the jwt generator.
No. This is a client side testing and debugging tool. A production authentication system should mint tokens from a trusted backend service that never exposes its signing secret to a browser, since anything typed into any browser based tool, including this one, should be treated as a test value rather than a genuinely protected secret.
Match whatever algorithm your backend or test suite expects to verify against, since a mismatch between the header's algorithm and the one actually used to sign will make any correct verifier reject the token. HS256 is the most common default, with HS384 and HS512 used where a longer hash output is specifically required.
The payload box requires valid JSON, the same syntax used everywhere else JSON appears, with double quoted keys and string values, no trailing commas, and correctly matched braces. This tool reports a specific parsing error so you can find and fix the exact problem in your payload rather than guessing.
No. The payload, the secret and the signing operation itself all stay inside a single call to SubtleCrypto.importKey followed by SubtleCrypto.sign, both of which return their result directly to the page rather than to any remote endpoint. That matters here specifically because people often paste in a real signing secret to build a test token, and the point of doing that locally is that the secret never has to leave the browser to begin with.
Yes. Since this jwt generator trusts whatever JSON you enter in the payload, setting exp to a timestamp in the past produces a token that is already expired, which is a genuinely useful way to test that your backend's expiry check actually rejects it as expected.
Yes. This page works as a jwt encoder online directly in your browser tab, with no software to install and no account required. Every step, from parsing the payload to signing the final token, runs on your own device.
Start from the default payload this tool provides, adjust the claims to match your test case, choose the algorithm your backend expects, and supply any test secret. That is enough to create json web token examples covering normal, expired or deliberately malformed claims for your test suite.
Use the same secret and the same HMAC algorithm on the verifying side, whether that is a backend library or a separate JWT decoding tool that supports signature verification. This generator itself only builds and signs tokens, it does not verify existing ones, since verification requires trusting the exact secret used to originally sign a given token.