JWT Encoder - Build & Sign Tokens in Your Browser

Create and sign JSON Web Tokens with HS256, HS384, or HS512. Edit the payload, add standard claims with one click, and sign with your secret. Secrets never leave your browser.

Privacy: signing happens with the Web Crypto API inside your browser. Your secret and payload are never transmitted or stored. Still, avoid pasting production secrets into any online tool; use a throwaway test secret.

JWT Encoder - Create and Sign JSON Web Tokens

Build a complete, signed JSON Web Token directly in your browser. Choose an HMAC algorithm (HS256, HS384, or HS512), edit the JSON payload with live validation, and sign with a plain-text or base64-encoded secret. The output shows the three token parts in distinct colors so you can see exactly where the header, payload, and signature begin and end, and a built-in round-trip check verifies the fresh signature against the signing input.

Backend developers use hand-built tokens to test API authorization middleware before the real identity provider is wired up. QA engineers craft tokens with specific claims, roles, or expiry times to exercise permission edge cases. Students and interview candidates use it to understand what actually goes into a JWT, and DevOps engineers generate quick test tokens for webhook signatures and service-to-service auth during local development.

A JWT is three base64url segments joined by dots. The header declares the algorithm and type, the payload carries claims, and the signature is an HMAC of the first two segments computed with your secret. The one-click claim buttons insert the registered claims most APIs expect: iat (issued at) as the current Unix timestamp, exp set one hour ahead, and a sub subject identifier. Because HMAC signing is symmetric, anyone holding the same secret can both create and verify tokens.

Signing uses the Web Crypto API (crypto.subtle), the same primitives browsers use for TLS, so nothing is sent to a server. For HS256 the secret should be at least 32 bytes of real entropy; short dictionary-word secrets can be brute-forced offline in minutes with tools like hashcat once an attacker captures a single token.

To inspect a token someone else issued, use our JWT Decoder, which breaks down the header and payload and checks expiry. If you need a strong signing secret, generate one with the Password Generator and store it in your secret manager rather than in code.

How the JWT Encoder Works

  1. 01Choose the HMAC algorithm: HS256, HS384, or HS512.
  2. 02Edit the JSON payload; validation flags errors instantly, and quick buttons insert iat, exp (+1 hour), and sub claims.
  3. 03Enter your secret (plain text or base64) and click Generate & sign - signing runs via the Web Crypto API in your browser.
  4. 04Copy the color-coded token; a built-in round-trip check confirms the signature verifies.

Building Test JWTs That Behave Like Real Ones

Start from the sample payload and shape it into what your API expects: a sub identifier for the user, role or scope claims for authorization checks, and the registered time claims. The quick buttons insert iat as the current Unix timestamp and exp one hour ahead, which mirrors what most identity providers issue; edit the numbers manually to simulate an expired or not-yet-valid token when testing rejection paths. Enter the same secret your server uses for verification. If your framework stores the secret base64 encoded (common with HS512 keys), tick the base64 checkbox so the raw key bytes match. After signing, the token appears with the header in indigo, payload in purple, and signature in amber, matching the layout of common JWT debuggers, and the round-trip check re-verifies the signature against the signing input so you know the token is internally consistent. Paste the token into an Authorization: Bearer header in curl, Postman, or your test suite. Because HMAC is symmetric, the server verifying with the same secret will accept it exactly as if its own auth service had issued it.

When to Use the JWT Encoder

Use it while developing or testing anything that consumes JWTs: API middleware, gateway authorization rules, webhook signature checks, or role-based access logic. It shines when the real identity provider is not available yet, when you need a token with an unusual combination of claims, or when you want an expired token on demand. Avoid pasting production signing secrets into any browser tool; use a development secret that only your test environment accepts.

Common Use Cases

  • Generating test tokens for API authorization middleware during local development
  • Crafting tokens with specific roles, scopes, or expiry times for QA edge cases
  • Producing an intentionally expired token to test rejection and refresh flows
  • Inspecting the produced token part by part JWT Decoder - Inspect Tokens Instantly
  • Generating a high-entropy signing secret first Strong Password Generator - Secure & Random

Expert Tips

  • Use a secret of at least 32 random bytes for HS256; short human-memorable secrets can be cracked offline from a single captured token.
  • Always set exp in test tokens - many middlewares reject tokens without it, and testing with realistic claims catches configuration surprises early.
  • Verify server-side that the alg header matches what you expect; accepting whatever algorithm a token declares is a classic JWT vulnerability.

Frequently Asked Questions

Does my secret leave the browser?→
No. Signing happens locally with crypto.subtle, the browser's built-in cryptography API. Nothing is transmitted, logged, or stored. Still, best practice is to use throwaway development secrets in any online tool.
Which algorithm should I pick?→
HS256 is the default in most frameworks and is sufficient for testing. HS384 and HS512 use longer digests; pick whichever matches your server configuration, since a mismatch makes verification fail.
What does the base64 secret checkbox do?→
Some systems store HMAC keys as base64 strings. With the box checked, the tool decodes the secret to raw bytes before signing, matching servers that decode the key. Unchecked, the literal UTF-8 bytes of what you typed are used.
Can this create RS256 tokens?→
No. RS256 requires an RSA private key, and asymmetric signing is a different workflow. This tool covers the symmetric HMAC family (HS256/384/512), which is what most local development and testing setups use.

Related tools

12 suggested