JWT Generator

Create and sign JSON Web Tokens with HS256/384/512

100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.

title Header
data_object Payload (Claims)
Custom Claims (JSON)
key Signing Secret
Generated Token
Signed JWT will appear here

Jump to the next useful tool without leaving your flow.

See more

About this tool

Create and signs JSON Web Tokens (JWTs) using HS256/384/512 algorithms - useful for testing an API that expects a JWT, learning how JWT structure works, or generating a token for a development/testing environment without setting up a full authentication server.

How to use this tool

  1. Define payload claimsSet subject, issuer, expiry, roles, and custom claims as needed.
  2. Choose signing algorithmSelect HS256/384/512 matching target API verification expectations.
  3. Sign token with secretGenerate JWT string and inspect decoded header/payload output.
  4. Test and verifyUse token in dev API requests and confirm auth behavior.

What to put in a JWT

Include the standard claims a server needs: sub (who the token is for), iat (issued at), exp (expiry) and often iss (issuer) and aud (audience). Keep the payload small, and never include passwords or secrets - anyone holding the token can read it.

Keep access tokens short-lived - 5 to 60 minutes is common - and use refresh tokens for longer sessions.

Key features

  • Speeds up API auth testing without full identity stack setup.
  • Helps visualize JWT structure and claim behavior.
  • Useful for QA, integration tests, and local debugging.
  • Supports common HMAC JWT signing variants.

Common uses

  • Testing protected API endpoints in development.
  • Simulating role-based tokens for frontend QA.
  • Debugging claim parsing and expiry handling logic.
  • Building auth test fixtures for automated integration suites.

Tips for better results

  • Use short expirations for testing security-sensitive flows.
  • Never use production signing secrets in browser tools.
  • Include only required claims to keep tokens minimal.
  • Validate algorithm expectations on server to prevent misuse.

Mistakes to avoid

  • Using generated dev tokens directly in production systems.
  • Forgetting expiry claim and creating long-lived insecure tokens.
  • Sharing JWTs publicly in logs or screenshots.
  • Assuming unsigned/weakly signed tokens are safe for auth.

Frequently asked questions

This tool is best suited for testing, learning, and development purposes - for real production authentication, tokens should be generated and signed server-side using your application's actual secret keys and infrastructure, not a third-party browser tool.

They're the same HMAC-based signing approach using different hash functions (SHA-256, SHA-384, SHA-512) - higher numbers mean a longer, more computationally intensive signature, though HS256 is the most commonly used default across most systems.

Signing happens in your browser, but as a general precaution, use a test/throwaway secret key here rather than a real production secret, especially since JWTs are often used for actual authentication.

Commonly sub (the user), iat (issued at), exp (expiry), and often iss (issuer) and aud (audience). Keep tokens small and do not put secrets in them - the payload is only base64-encoded, not encrypted.

Short-lived access tokens of 5-60 minutes are typical, paired with a refresh token for longer sessions. A long-lived JWT cannot easily be revoked if it leaks.

At least 256 bits (32 random bytes) for HS256, and longer for HS384 and HS512. A short or guessable secret lets attackers forge valid tokens.

Related guides