Batch Toolkit

BatchToolkit signs JSON Web Tokens entirely in your browser so secrets never leave your device. Use this guide to understand JWT structure, generate secure tokens, and verify them with confidence.

Ready to create a token right away? Open the JWT generator in a new tab and follow along.

Before you start
What makes a secure JSON Web Token
Generate a JWT in five straightforward steps
Recommended claims for production
Verify and debug tokens
Hardening checklist

Before you start

Have a shared secret or signing key ready for HS256/HS512 workflows.
Know which audience (aud) and issuer (iss) values your services expect.
Use a modern browser (Chrome, Edge, Firefox, Safari) to keep Web Crypto fast and offline.

What makes a secure JSON Web Token

A JSON Web Token combines three base64url-encoded parts: the header, payload, and signature. The header names the signing algorithm (for example HS256) and token type, the payload carries the claims you care about, and the signature proves the payload was issued by you without tampering.

Keep payloads lightweight—anything inside the token is visible to clients. Move sensitive or lengthy data into your database and reference it with an identifier inside the JWT.

header.payload.signature

BatchToolkit signs tokens locally with Web Crypto, so your secrets stay on this device.

Generate a JWT in five straightforward steps

Select the signing algorithm that matches your API expectations. HS256 is a safe default for HMAC.
Paste your shared secret. The field trims accidental whitespace but never sends the secret to our servers.
Describe the payload in JSON. Include at minimum sub (subject) so downstream services know who the token represents.
Enable helper toggles to auto-fill iat, nbf, and exp. Move the expiry slider to the lifetime you allow.
Press Generate JWT and copy the full token or individual segments for use in Postman, cURL, or automated tests.

Drop the token into the Authorization: Bearer <token> header of your request. Need a tweak? Update the claim values and regenerate instantly.

Recommended claims for production

Identity & tenancy

sub: stable user or service identifier.
iss: issuer, usually your API origin (for example https://api.example.com).
aud: audience, the consumer service expected to validate the token.

Session lifecycle

iat: issued-at timestamp for auditing.
nbf: not-before guard to prevent replay before a given time.
exp: expiration enforcing short-lived access.

Authorization context

scope or permissions: describe the capabilities granted.
roles: list the roles active for this session.
jti: unique ID used to revoke the exact token if compromised.

Custom additions

Keep custom fields concise and non-sensitive.
Persist complex state elsewhere and store only reference IDs inside the JWT.

Verify and debug tokens

Validation is as important as generation. Pair the JWT generator with the decoder to troubleshoot quickly.

Paste the token into your application or API middleware and run the request.
If you receive an error, open the JWT decoder to inspect the header and payload.
Compare timestamps with your server clock and adjust expiry or skew tolerance when needed.
Regenerate using the saved settings to issue a corrected token.

In production, enforce signature verification, reject algorithm downgrades, and fail fast when tokens are expired or malformed.

Hardening checklist

Rotate signing secrets frequently and store them in a secrets manager.
Use the strongest algorithm available to your consumers (HS512 for symmetric signing).
Limit token lifetime and prefer short expirations coupled with refresh workflows.
Scope the payload to the minimum claims a client needs; avoid placing PII or bulk data inside the JWT.
Always validate the audience, issuer, and expiration before trusting the token.

Need another feature or guide? Tell us what would help you next.