Generate JWT Tokens Free — Offline Tool Guide

✓ Last tested: May 2026 · Verified against RFC 7519 (JSON Web Token Standard)

1. Field Notes: The Day I Almost Leaked Staging Credentials to a Random Server

A few years ago, I was integrating a new Node.js microservice that relied on JSON Web Tokens (JWT) for authentication. I needed to quickly mock a valid token for a test user to verify my authorization middleware. Like many developers, I immediately Googled "how to generate jwt token online free", clicked the first search result, pasted my staging environment's JWT secret, tweaked the sub claim for the test user, and hit generate.

It worked flawlessly. I copied the token, pasted it into Postman, and successfully hit the protected endpoint.

But out of sheer curiosity, I opened the browser's Network tab. To my absolute horror, I saw a POST request firing off to that tool's backend API. The request body contained my complete JWT payload and my staging server's HMAC signing secret in plaintext.

If that site was logging requests—which most generic tools do for analytics or debugging—they now had the keys to forge admin tokens for our entire staging environment. We immediately had to halt testing, rotate all the staging secrets across our services, and audit our environment logs for unauthorized access. That incident hammered home a critical lesson: never paste cryptographic keys or secrets into online tools that process data on a server.

This is exactly why we built a completely client-side, offline JWT Generator on WebToolkit Pro. In this extensive guide, I'll walk you through how to construct, generate, and verify JWTs securely without ever sending your data across the wire.

---

2. How to Generate JWT Tokens Free and Offline

Generating a JSON Web Token (JWT) involves constructing three distinct parts: a Header, a Payload, and a Signature. While many developers rely entirely on backend libraries like jsonwebtoken in Node or PyJWT in Python to generate tokens programmatically, there are times—such as during API testing, initial setup debugging, or frontend state development—when you need to manually generate a token.

Here is exactly how to do it correctly and securely.

What You Need Before Generating a JWT

Before you begin token generation, you must have three architectural decisions locked down for your system:

1. The Signing Mechanism: Will you use a symmetric key (where the exact same string secret is used to both sign and verify) or an asymmetric key pair (a private key exclusively used to sign, and a public key widely distributed to verify)?
2. The Claims Dictionary: What data does the receiving API service strictly expect in the payload? Does it enforce standard claims like iss (Issuer) and aud (Audience), or does it simply look for a sub (Subject)?
3. A Secure Client-Side Tool: You need a tool that executes entirely in the browser using the Web Crypto API or local JavaScript libraries, ensuring no data transmission over the internet.

---

3. How to Build a JWT Header and Payload

A JWT is fundamentally just a Base64Url-encoded JSON string, but its contents and formatting dictate how the server parses, trusts, and validates it.

Choosing Your Algorithm (HS256 vs RS256)

The header determines the cryptographic algorithm used to secure the token. The two most prominent algorithms are HS256 and RS256.

• HS256 (HMAC with SHA-256): A symmetric algorithm. You use a single shared secret string (e.g., super-secret-key-123!) to both generate the token and verify it. This is much simpler to implement but dangerous in distributed microservices architectures. Why? Because every downstream service that needs to verify the token must possess the shared secret, giving them the power to create valid tokens as well.
• RS256 (RSA Signature with SHA-256): An asymmetric algorithm. You use an RSA Private Key to generate and sign the token (usually locked away tightly in your authentication server), and an RSA Public Key to verify it. This is the enterprise industry standard for microservices and Single Sign-On (SSO) architectures. You can safely distribute the Public Key to any downstream service without risking token forgery.

Header Example (RS256):

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

Required Claims vs Custom Claims

The payload contains "claims," which are statements about an entity (typically, the user) and any additional metadata. According to RFC 7519, claims are broadly divided into Registered, Public, and Private claims.

For a robust and standard-compliant token generation, you should always include these registered claims:

• sub (Subject): The unique identifier for the user (e.g., UUID, email, or database user ID).
• iss (Issuer): The URI or canonical name of the server issuing the token.
• aud (Audience): The intended recipient of the token.
• iat (Issued At): The exact timestamp when the token was created.

Custom claims can be added as needed (e.g., roles, permissions, tenant_id), but be extremely mindful of token size bloat. JWTs are sent in the HTTP Authorization header on every single request; a massive, bloated token will drastically degrade network performance and can even cause HTTP 431 Request Header Fields Too Large errors.

{
  "sub": "user_987654321",
  "name": "Abu Sufyan",
  "roles": ["admin", "editor"],
  "iat": 1717142400,
  "exp": 1717146000
}

Setting the Expiry Correctly

The exp (Expiration Time) claim is arguably the most mishandled field in JWT generation. It defines the exact moment the token becomes entirely invalid.

Critical Rule: The exp claim must be a NumericDate value representing seconds since the Unix Epoch (1970-01-01T00:00:00Z).

Many developers accidentally use JavaScript's Date.now(), which returns milliseconds. If you use milliseconds, your token's expiration date will be set thousands of years into the future (e.g., the year 54210), rendering the expiration functionally useless and introducing a massive security vulnerability. Always do Math.floor(Date.now() / 1000) when calculating current time programmatically.

---

4. Generating a JWT Token Step by Step

To securely generate a JWT without risking leaking your secrets across the web, you should use an offline, strictly client-side tool. Here is a comprehensive walkthrough using our WebToolkit Pro JWT Decoder & Generator.

Step 1: Open the Offline JWT Generator

Navigate to the tool. Because it is engineered to run purely in your browser's local execution environment via JavaScript, you can safely use it even while physically disconnected from the internet. You can turn off your Wi-Fi right now and it will still work perfectly.

Step 2: Configure the Header and Select the Algorithm

Select your required cryptographic algorithm from the dropdown interface (e.g., HS256). The tool will automatically format and inject the correct JSON header:

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

Step 3: Populate the Payload

Input your JSON payload. Ensure your JSON is strictly valid (using double quotes around keys). Add your sub, custom roles, and manually calculate an exp timestamp in seconds. Expert Tip: You can use a Unix timestamp converter tool to grab a timestamp exactly 1 hour or 24 hours into the future to simulate short-lived and long-lived tokens.

Step 4: Supply the Cryptographic Material

• If using HS256, paste your staging or test HMAC secret into the "Secret" input field.
• If using RS256, you will need to paste your PEM-formatted RSA Private Key (which typically begins with -----BEGIN PRIVATE KEY-----).

Step 5: Encode and Sign

Click the generate button. Behind the scenes, the tool performs the following operations locally in your browser memory:

1. It Base64Url-encodes the Header JSON string.
2. It Base64Url-encodes the Payload JSON string.
3. It concatenates both strings with a period character (.).
4. It signs the concatenated string using your provided secret/key and the selected algorithm.
5. It Base64Url-encodes the resulting binary signature.
6. It appends the encoded signature to create the final header.payload.signature string.

You now have a valid, securely generated JWT ready for API testing.

---

5. How to Verify Your Generated Token

Once you have generated the token, you must ensure your backend service actually accepts and parses it correctly. Verification is essentially the exact inverse of generation.

When your backend API server receives the token:

1. It splits the token string into its three constituent parts by the period character.
2. It takes the original Base64Url-encoded Header and Payload, and recalculates the signature using the server's known secret (for HS256) or the shared Public Key (for RS256).
3. It performs a cryptographic constant-time comparison of its calculated signature against the signature attached to the token. If they match precisely, it proves the payload has not been tampered with.
4. It decodes the payload and checks the exp claim against the current server time to ensure the token hasn't expired.

You can test this verification logic locally using OpenSSL or Node.js. Here is a quick Node.js snippet utilizing the native crypto module to verify an RS256 token:

const crypto = require('crypto');
const fs = require('fs');

// The token you generated
const token = "eyJhbG... (your full token)";
const [encodedHeader, encodedPayload, encodedSignature] = token.split('.');

// Read your public key from disk
const publicKey = fs.readFileSync('./public.pem', 'utf8');

// Initialize verification using RSA-SHA256
const verifyFunction = crypto.createVerify('RSA-SHA256');
verifyFunction.write(`${encodedHeader}.${encodedPayload}`);
verifyFunction.end();

// Convert the Base64Url signature back to a buffer
const signatureBuffer = Buffer.from(encodedSignature, 'base64url');

// Verify the signature against the public key
const isValid = verifyFunction.verify(publicKey, signatureBuffer);

console.log("Is token valid?", isValid);

---

6. Common JWT Generation Mistakes

After auditing numerous enterprise implementations and testing various offline JWT setups, here are the most frequent pitfalls developers encounter when generating and managing tokens:

• Mistake 1: Using Standard Base64 instead of Base64Url Encoding. Standard Base64 encoding includes characters like +, /, and =. These characters have special meaning in URLs and HTTP headers, which can truncate or corrupt the token during transmission. The JWT specification explicitly requires Base64Url encoding, which strictly replaces + with -, / with _, and completely strips the trailing padding = characters.
• Mistake 2: Vulnerability to the "alg: none" Attack. The initial JWT specification technically supported a none algorithm designed for unsigned tokens. Malicious actors sometimes manipulate the header to {"alg": "none"}, strip the signature entirely, and pass it to the server. If your backend validation logic doesn't explicitly enforce the required algorithm, it might blindly accept the unsigned token. Always hardcode the expected algorithm (e.g., algorithms: ['RS256']) in your verification middleware.
• Mistake 3: Storing Sensitive Data in the Payload. A JWT is cryptographically signed to prevent tampering, but it is not encrypted by default. Anyone who intercepts the token—or finds it in local storage—can Base64-decode the payload and read its contents in plain text. Never put passwords, API keys, internal network IP addresses, or PII (Personally Identifiable Information) inside a standard JWT payload. Use opaque tokens if you need to hide payload data.

---

Frequently Asked Questions

Q: Is it safe to generate JWT tokens online? A: No, unless the tool runs entirely client-side. Many online tools send your signing secret or private key to a backend server to generate the token, which is a major security risk for staging or production secrets.

Q: What is a JWT signature secret? A: A JWT signature secret is the cryptographic key used by the HMAC algorithm (like HS256) to sign the token payload. It proves the token was generated by your server and hasn't been tampered with.

Q: Can I use RS256 for symmetric signing? A: No. RS256 is an asymmetric algorithm that uses a private key for signing and a public key for verification. For symmetric signing where the same secret is used for both, use HS256.

Q: How do I generate a JWT in Postman? A: Postman can generate JWTs using its Pre-request Scripts. You can write a JavaScript snippet utilizing the built-in crypto-js library to construct the Base64Url-encoded header and payload, and then sign it with HMAC-SHA256.

---

Test your configuration directly in your browser. Use our free Offline JWT Decoder & Generator to build JWTs securely without ever sending your keys to a server →

---

External Sources

• RFC 7519: JSON Web Token (JWT) Standard Specification
• OWASP JSON Web Token Cheat Sheet
• Auth0 JWT.io Introduction to JSON Web Tokens

---

Abu Sufyan · Full-stack developer · Founder of WebToolkit Pro Github

Last updated: May 2026