Build an API fixture
Mint a short-lived HS256 token for a local server, integration test, or documented example.
All developer toolsRuns locally in your browser
FREE BROWSER TOOL
JWT Generator
Generate and inspect HS256 JSON Web Tokens in your browser. Build a local payload, sign it with a development secret, and decode header and claims without uploading the token.
Use JWT generator now.
Create and inspect HS256 JSON Web Tokens locally. Your result updates in the current tab as you work.
JWT Generator
Create and inspect HS256 JSON Web Tokens locally. Nothing you enter here is uploaded or stored.
HS256 only. Set expiry to 0 to omit exp. Use a development secret, never a production key.
Signed HS256 token
Your result will appear here.
WHAT IT DOES
Useful when a small detail is blocking the next step.
A JSON Web Token is a compact, three-part string: a Base64URL header, a Base64URL payload of claims, and a signature. This workspace signs HS256 tokens in the current tab so you can build fixtures, inspect claims, and confirm your own development secret—without treating the result as a production credential.
Inspect encoded claims
Decode a development token to see issuer, subject, audience, and expiry before writing a verifier.
Confirm a local secret
Sign a known payload, then verify the same token with the secret your development API is configured to use.
WORKED EXAMPLES
See the exact decision the tool can help you make.
These examples are specific to JWT generator. Replace their values with your own, then use the result as a clue—not as a substitute for application validation.
Create a local session fixture
A development API expects a compact HS256 token with a subject and a short expiry.
INPUT
payload: {"sub":"dev-user","iss":"local-app"}
secret: local-dev-only
expiry: 15 minutesRESULT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.<claims>.<signature>
The first section names HS256. The second section carries the claims you typed, plus iat and exp when expiry is set. The third section is an HMAC of those two parts using your local secret.
Read claims before wiring a verifier
A teammate sent a development token and you need to confirm the audience claim.
INPUT
token: header.payload.signature
RESULT
alg: HS256 aud: local-dev exp: present as a Unix timestamp
Decoding shows the claims the issuer encoded. It does not prove the token is trusted until your server verifies the signature with the expected secret and rejects unexpected issuers, audiences, and expired values.
HOW TO USE IT
Three deliberate steps.
Use the result to make a decision in your code or content, not merely to produce another value to copy.
- 01
Write the claims as JSON
Include only the fields your local API expects. Typical development claims are sub, iss, aud, and a short exp.
- 02
Sign with a local secret
Use a development-only shared secret. The tool creates an HS256 signature in this browser tab and never uploads the payload or key.
- 03
Verify on the server before trusting it
Copy the compact token into your own verifier. Check the signature, expiry, and claims there—not only in this preview.
JWTs are credentials when they grant access
A compact token can leak through logs, analytics, URLs, and shared screenshots. Prefer Authorization headers over query strings, keep lifetimes short, store production secrets on the server, and revoke or rotate keys when a token or secret is exposed.
HS256 proves that the header and payload were signed with a shared secret. Your API still has to reject alg none, unexpected algorithms, expired tokens, and subjects that are not allowed to perform the requested action. Keep verification and authorization on the server.
header.payload.signature
Verify: HMAC-SHA256(secret, header + "." + payload)
Then check: exp, nbf, iss, aud, sub
Never accept: alg "none" or a client-chosen algorithm.COMMON PITFALLS
Use the result without creating the next bug.
Each tool is deliberately narrow. These are the mistakes most likely to appear when its output is copied into a real product without checking the surrounding constraint.
Treating a generated JWT as proof that a user is authenticated in production.
Why it matters: Anyone who learns the secret can mint a matching token. The browser tool cannot enforce issuer, audience, expiry, or revocation.
Better approach: Verify HS256 signatures on the server with a secret that never ships in client code, then check exp, nbf, iss, aud, and the subject against your authorization rules.
Pasting a production signing key into a browser field.
Why it matters: The secret is visible to this tab, extensions, and anyone looking at the screen. A leaked production key lets an attacker mint tokens your API would accept.
Better approach: Use a dedicated local-development secret. Keep production keys in a server secret store and rotate them if they are ever exposed.
FAQ
Questions worth answering before you rely on the result.
These tools help with bounded client-side work. Production decisions still need the validation, review, and authorization appropriate to your application.
01Is a JWT encrypted?
Not in this tool. HS256 signs the header and payload so they cannot be altered unnoticed, but the claims remain readable after Base64URL decoding. Do not put passwords or other secrets in the payload.
02Why only HS256?
HS256 is the shared-secret algorithm used for many local fixtures. Asymmetric algorithms such as RS256 need a private key held on a server, which does not belong in a browser workspace.
03Does inspecting a token verify it?
Decoding reads the header and payload. Verification happens only when you supply the matching HS256 secret. Production APIs must still enforce expiry, issuer, audience, and authorization independently.
KEEP BUILDINGMore small tools,