JWT Generator Best Practices and Common Mistakes

The single most important JWT rule: keep your HS256 secret on the server only, because anyone who holds it can mint valid tokens. Generating test tokens in the browser is perfectly safe, but shipping the same mindset to production is where teams get burned. Here are the practices, pitfalls and fixes that matter.

Best practices

• Use a long, random secret. HS256 security depends entirely on secret strength. A short or guessable secret makes the signature forgeable — treat it like a password, at least 32 random bytes.
• Always set an expiry. Add an exp claim so tokens age out. Long-lived tokens are a standing liability if one leaks.
• Include iat and, when useful, nbf. Issued-at and not-before claims let servers reason about token freshness and validity windows.
• Keep the payload small. Every claim rides in every request; bloated payloads waste bandwidth and tempt you to store data that does not belong there.

Common mistakes to avoid

Troubleshooting

"My server rejects the signature." The secret used to generate must match the secret used to verify, byte for byte. Watch for trailing whitespace, different encodings, or a secret that was base64-decoded on one side but not the other.

"The token is malformed." The generator validates the header and payload JSON before signing, so a malformed token usually means the JSON had a syntax error that was fixed — regenerate and copy the whole string, including both dots.

"The token is already expired." Check that your exp is a future Unix timestamp in seconds, not milliseconds. A millisecond value is thousands of years off and often reads as long past.

A note on browser signing

Signing here happens locally through the Web Crypto API, so your secret and claims never leave the page — ideal for development. Just remember the browser is the right place to test tokens, not to hold production secrets that end users could reach.

Try the JWT Generator — free and 100% in your browser.

FAQ

How long should my HS256 secret be?

At least as long as the hash output — 256 bits (32 bytes) of randomness for SHA-256 — and ideally more. Longer, high-entropy secrets resist brute-force attempts against the signature.

Is it safe to reuse a token across services?

Only if all services share the secret and trust the same issuer and audience. Use aud and iss claims so each service can confirm a token was actually meant for it.

Should I put user roles in the payload?

Non-sensitive authorization hints like a role name are common and fine, since the server re-verifies them. Never rely on the payload for anything secret, and always re-check permissions server-side.

What is the difference between encoding and encrypting here?

The header and payload are base64url-encoded — reversible by anyone. The signature only proves integrity, not confidentiality. If you need the payload hidden, that requires encryption on top of the JWT.

Related free tools

• JWT Decoder — read and verify token contents.
• SHA-256 Hash Generator — compute SHA-256 hashes.
• Base64 Encoder — encode or decode base64 segments.
• Basic Auth Header Generator — generate Basic auth headers.

Built by ByteVancer

ByteTools is a free product of ByteVancer, a software and web development studio building web apps, SaaS and custom software. If you want a team that treats auth and security as first-class, explore ByteVancer's services.