DevBolt
Processed in your browser. Your data never leaves your device.

How do I create and sign a JWT token online?

Build a JWT visually — set standard claims (iss, sub, aud, exp, iat, nbf, jti), add custom claims with type selection, choose an algorithm (HMAC, RSA, or ECDSA), and generate a signed token. The tool creates key pairs in your browser for RSA/ECDSA. Your secrets never leave your device.

Build authentication JWT
Input
Algorithm: HS256
Secret: my-secret-key
Claims:
  sub: user_123
  role: admin
  exp: 1 hour
Output
Header: {"alg":"HS256","typ":"JWT"}

Payload: {
  "sub": "user_123",
  "role": "admin",
  "iat": 1742515200,
  "exp": 1742518800
}

eyJhbGciOiJIUzI1NiIs...
  .eyJzdWIiOiJ1c2VyXz...
  .SflKxwRJSMeKKF2QT4f...
← Back to tools

JWT Builder

Build and sign JSON Web Tokens with custom claims and your choice of HMAC, RSA, or ECDSA algorithms. All signing happens in your browser.

Presets:

The secret is used to sign the token. Keep it safe — never share production secrets.

Standard Claims

Who issued this token
Who the token is about
Intended recipient
Unique token identifier

Custom Claims

No custom claims. Click "Add Claim" to add key-value pairs.

Payload Preview

{
  "iat": 1774477725,
  "exp": 1774481325
}

Algorithm Reference

HMAC (symmetric)

HS256 / HS384 / HS512

Shared secret key. Simple setup. Both signer and verifier need the same key.

RSA (asymmetric)

RS256 / RS384 / RS512

Public/private key pair. Private key signs, public key verifies. Most common in production.

ECDSA (asymmetric)

ES256 / ES384 / ES512

Elliptic curve keys. Smaller keys, same security as RSA. Faster verification.

Complement to JWT Decoder. Build tokens here, decode and inspect them there.

Tips & Best Practices

Pro Tip

Use RS256 for multi-service architectures, HS256 for single-service

HS256 (symmetric) uses one shared secret — any service that can verify a JWT can also create one. RS256 (asymmetric) uses a private key to sign and a public key to verify. In microservice architectures, RS256 lets services verify tokens without having the signing key.

Common Pitfall

Never set excessively long expiration times

JWTs cannot be revoked — once issued, they're valid until expiration. A JWT with exp set to 1 year means a leaked token grants access for up to a year. Use short-lived access tokens (5-15 minutes) paired with refresh tokens for session management.

Real-World Example

Include only the minimum necessary claims in the payload

JWTs are sent with every request — large payloads waste bandwidth. Include only identity (sub), permissions (role), and expiration (exp, iat). Don't embed user profiles, preferences, or other data that can be fetched from your API when needed.

Security Note

Never use the 'none' algorithm in production

The alg: 'none' option creates unsigned tokens — useful for development and testing only. Attackers exploit misconfigured JWT libraries by sending tokens with alg: 'none' to bypass signature verification. Always validate the algorithm server-side and reject 'none' in production.

Frequently Asked Questions

How do I create and sign a JWT token?
Select an algorithm (HS256, RS256, ES256, or others), configure the header and payload claims using the visual editor, and provide a signing key. DevBolt's JWT Builder supports 10 algorithms: HMAC (HS256/384/512), RSA (RS256/384/512), ECDSA (ES256/384/512), and unsigned (none). For HMAC, enter a shared secret. For RSA and ECDSA, generate a key pair directly in the browser or paste your own. Standard claims like iss, sub, aud, exp, iat, nbf, and jti have dedicated fields with auto-populate. All signing runs client-side via the panva/jose library.
What is the difference between HS256 and RS256 for JWT signing?
HS256 uses a single shared secret for both signing and verification — simpler but requires distributing the secret to every verifying service. RS256 uses asymmetric cryptography: a private key signs and a public key verifies. RS256 is preferred for distributed systems because only the auth server needs the private key while any service can verify using the public key. HS256 is faster and suitable for single-service applications. Most auth providers default to RS256.
What standard claims should I include in a JWT?
Essential claims include: iss (issuer — who created the token), sub (subject — the user or entity), aud (audience — intended recipient service), exp (expiration — Unix timestamp when the token expires), iat (issued at — creation time), and jti (JWT ID — unique identifier to prevent replay attacks). Optional claims include nbf (not before — earliest valid time). Always set exp to limit token lifetime. DevBolt auto-populates iat with the current time and generates UUID values for jti.

Related Generate Tools