JWT Token Generator: Create and Sign JSON Web Tokens

What Are JSON Web Tokens?

JSON Web Tokens (JWTs) are a compact, URL-safe means of representing claims to be transferred between two parties. The claims are encoded as a JSON object used as the payload of a JSON Web Signature structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code. In practical terms, a JWT is a string of three Base64Url-encoded parts separated by dots: xxxxx.yyyyy.zzzzz.

The first part is the header, specifying the token type and signing algorithm. The second part is the payload containing the actual data or claims about an entity (typically the user). The third part is the signature ensuring the token integrity. This simple three-part structure makes JWTs ideal for stateless authentication in web applications, microservices architectures, and single sign-on systems across distributed platforms.

Since their standardization in RFC 7519, JWTs have become the de facto standard for token-based authentication worldwide. Major platforms like Google, Microsoft, Auth0, and Firebase use JWTs extensively for their authentication flows. Understanding how to generate, sign, and validate JWTs is a critical skill for modern web developers, API designers, and security engineers. Our JWT Token Generator simplifies this process with an intuitive visual interface.

Anatomy of a JWT Token

The Header

The header is a JSON object specifying the token type and signing algorithm, Base64Url-encoded to form the first part of the JWT:

{
  "alg": "HS256",
  "typ": "JWT"
}

The alg field declares which algorithm was used to sign the token. Common values include HS256 (HMAC-SHA256), RS256 (RSA-SHA256), and ES256 (ECDSA-SHA256). The typ field indicates the media type, almost always set to "JWT".

The Payload

The payload contains the claims, which are statements about an entity and additional metadata. There are three categories of claims: registered claims (predefined names like iss, sub, exp), public claims (defined in the IANA registry), and private claims (custom names agreed upon between parties):

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "role": "admin",
  "iat": 1718294400,
  "exp": 1718380800
}

Key registered claims include iss (issuer identifying who created the token), sub (subject identifying the principal), aud (audience specifying intended recipients), exp (expiration time after which the token is invalid), nbf (not before time), and iat (issued at time). The expiration claim is particularly critical for security because tokens without expiration can theoretically be used indefinitely if compromised.

The Signature

The signature is created by combining the encoded header, encoded payload, and a secret key (for HMAC) or private key (for RSA/ECDSA), then signing the result with the specified algorithm. This cryptographic step ensures the token has not been modified during transit:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  your-256-bit-secret
)

Anyone with access to the shared secret (symmetric) or the public key (asymmetric) can verify the signature, confirming both the token authenticity and data integrity.

JWT Signing Algorithms Explained

HMAC (HS256, HS384, HS512)

HMAC algorithms use a shared secret key for both signing and verification. The same key must be kept secure on both the issuing and verifying servers. HS256 is the most widely used HMAC algorithm, suitable for scenarios where a single trusted service both issues and validates tokens. The main security risk is key compromise because if the secret is leaked, anyone can forge tokens with arbitrary claims.

RSA (RS256, RS384, RS512)

RSA algorithms use a public/private key pair. The issuing service signs with the private key, and any service can verify using only the corresponding public key. This makes RS256 ideal for distributed microservices where multiple services need to validate tokens independently without sharing a signing secret. RS256 is the recommended algorithm for production JWT implementations due to its strong security properties and widespread library support.

ECDSA (ES256, ES384, ES512)

ECDSA provides similar asymmetric capabilities to RSA but with shorter keys and faster operations. An ES256 signature using a 256-bit key provides security comparable to an RS256 signature with a 3072-bit key. This makes ECDSA tokens smaller and more efficient, which matters significantly in bandwidth-constrained environments like mobile APIs and IoT devices.

How to Generate a JWT Token

Generating a JWT token involves three steps: creating the header JSON, creating the payload JSON with your claims, and signing the combination with your chosen algorithm and secret or key. While you can do this programmatically in any language, our JWT Token Generator provides a no-code approach where you simply select the algorithm, enter your payload claims, provide the secret or key, and instantly receive a complete, signed token ready to use.

For programmatic generation in Node.js, the popular jsonwebtoken library makes this straightforward:

const jwt = require('jsonwebtoken');
const token = jwt.sign(
  { sub: '12345', name: 'Jane Doe', role: 'admin' },
  'your-secret-key',
  { expiresIn: '1h', algorithm: 'HS256' }
);

In Python, the PyJWT library serves the same purpose with a clean, simple API:

import jwt
token = jwt.encode(
    {"sub": "12345", "name": "Jane Doe", "role": "admin"},
    "your-secret-key",
    algorithm="HS256"
)

JWT in Authentication Workflows

The most common JWT authentication flow works as follows: the user submits credentials (username and password) to the server, the server verifies them against the database and returns a signed JWT, the client stores the token (ideally in an httpOnly, secure, SameSite cookie) and includes it in subsequent requests via the Authorization header as a Bearer token. The server validates the token signature and expiration on every request, granting or denying access accordingly without needing to query a session database.

This stateless approach eliminates the need for server-side session storage, making it perfect for horizontally scaled microservices architectures. Each service can independently verify tokens using the shared secret or public key, without needing to query a central session store or coordinate state between instances. This dramatically simplifies infrastructure requirements and improves system reliability and scalability.

JWT Security Best Practices

Security should be the top priority when implementing JWT-based authentication. Essential best practices include: always use strong algorithms and prefer RS256 or ES256 over HS256 for production systems where multiple services validate tokens. Set short expiration times (15-30 minutes for access tokens) and implement refresh token rotation for longer sessions. Store tokens exclusively in httpOnly, secure, SameSite cookies rather than localStorage, which is vulnerable to cross-site scripting attacks. Never include sensitive data (passwords, Social Security numbers, credit card numbers) in the JWT payload because the payload is only base64-encoded, not encrypted, and can be decoded by anyone who intercepts the token. Validate all claims on the server side, not just the signature. Use a cryptographically strong, randomly generated secret key for HMAC (at least 256 bits). Implement proper token revocation mechanisms using deny lists or versioned secrets for handling compromised tokens.

Common JWT Vulnerabilities

Despite their apparent simplicity, JWTs can be misused in ways that create serious security vulnerabilities. The most dangerous is the algorithm confusion or algorithm substitution attack, where an attacker modifies the alg header to "none" and removes the signature entirely, or switches from RS256 to HS256 using the RSA public key as the HMAC secret (which is publicly available). Always validate the algorithm explicitly on the server side and reject any unexpected algorithm values.

Other common vulnerabilities include: missing expiration dates allowing tokens to be valid indefinitely, weak secrets that can be brute-forced with modern hardware, storing tokens in localStorage where they are accessible to any JavaScript running on the page (including malicious scripts from XSS attacks), failing to validate the aud (audience) claim which could allow tokens intended for one service to be accepted by another, and using symmetric algorithms (HS256) in distributed systems where the secret must be shared across multiple services creating additional attack surface.

When to Use JWT (And When Not To)

JWTs excel in stateless authentication for REST APIs, microservices communication, SSO systems, and mobile application backends. They are ideal when you need to pass claims between different services without maintaining a central session store, or when horizontal scalability requires that any instance can independently validate tokens. However, JWTs are not always the best choice. If you need to immediately revoke individual sessions (like when a user explicitly logs out), traditional server-side sessions with a shared store like Redis are simpler and more effective. For very short-lived operations, opaque tokens with server-side storage may be more appropriate. The key is understanding your specific requirements around state management, session revocation needs, and scalability constraints before choosing your authentication approach.

Ready to generate your first token? Try our free JWT Token Generator to create, sign, and decode tokens instantly right in your browser.

Try the Tool →