Online JWT Generator/Decoder: JSON Web Token Tool

What Is JWT

JWT (JSON Web Token) is a compact, URL-safe token format for securely transmitting information between parties. It consists of three parts:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
|________ Header ________| |________ Payload ________| |________ Signature ________|

Three-Part Structure

Why You Need JWT

1. Stateless authentication: Server stores no session info
2. Cross-origin support: Naturally supports CORS
3. Microservice communication: Securely pass user identity between services
4. API access control: Protect API endpoints
5. Single Sign-On (SSO): Shared auth state across systems
6. Mobile authentication: Ideal for frontend-backend separation

JWT vs Session

How to Use the On-Site JWT Generator

Using ToolVault's JWT Generator:

1. Pick a signing algorithm: HS256 / HS384 / HS512 (local HMAC via Web Crypto)
2. Apply a claim template (Access / Refresh / Service) or edit the Payload JSON by hand
3. Use exp shortcuts (5 minutes through 24 hours, or “already expired”) and “nbf = now”
4. Enter a test HMAC secret → mint a compact JWS
5. Copy into Authorization: Bearer, or open the JWT Decoder to inspect Header / Payload / timeline

Snowflake-style IDs beyond JavaScript’s safe integer range keep their raw digits through mint → decode. Asymmetric algorithms (RS256/ES256) need a private key and should be issued on the server; the decoder still helps you read those claims.

JWT in Code

Node.js (Generate and Verify)

const jwt = require('jsonwebtoken');

// Generate JWT
const token = jwt.sign(
  { sub: '12345', name: 'Alice', role: 'admin' },
  'your-secret-key',
  { expiresIn: '24h' }
);

// Verify JWT
const decoded = jwt.verify(token, 'your-secret-key');
console.log(decoded); // { sub: '12345', name: 'Alice', ... }

Python

import jwt
from datetime import datetime, timedelta, timezone

# Generate JWT
payload = {
    'sub': '12345',
    'name': 'Alice',
    'exp': datetime.now(timezone.utc) + timedelta(hours=24)
}
token = jwt.encode(payload, 'your-secret-key', algorithm='HS256')

# Verify JWT
decoded = jwt.decode(token, 'your-secret-key', algorithms=['HS256'])
print(decoded)

Signing Hygiene

1. Use strong secrets: At least 256 bits of entropy for HS256; short human passphrases are not enough
2. Set short expiration: Access tokens commonly sit around 15 minutes
3. Use Refresh Tokens: Long-lived refresh, short-lived access
4. Don't store sensitive data: Payload is Base64URL, not encryption
5. Use HTTPS: Prevent token theft in transit
6. Always verify signatures: Pin allowed algorithms server-side; never trust the header alg blindly

Choosing the signing algorithm

The matrix most teams need: HS256 (HMAC with a shared secret) for single-service tokens where key distribution is a solved problem — simple, but any party that verifies can also forge. RS256/ES256 (asymmetric) the moment a second service must verify tokens: sign with the private key, publish the public key (usually a JWKS endpoint), verifiers never hold signing power. ES256 often beats RS256 on token size and speed at equal security strength. Reject alg: none in any verifier — the 2015 alg-confusion attacks were born there. And pin the algorithm server-side: never trust the header's alg claim to decide which verification path to run.

The on-site generator covers the three HMAC tiers because Web Crypto behaves consistently for HMAC across browsers; EdDSA/asymmetric minting waits on browser fragmentation converging — see Why Ed25519 matters.

exp, iat, and clock skew

The three temporal claims cause more production outages than cryptography does. exp is verified as "now must be before exp", but two machines rarely agree on "now": a 5-second skew between the issuer and the verifier rejects perfectly valid tokens. The standard remedy is leeway (accept tokens up to N seconds past exp — 30–60s is common), not clock-sync crusades. iat should be in the past; nbf (not-before) in the future blocks replay of pre-issued tokens. A generator that omits exp entirely produces tokens that never expire — fine for tests, an audit finding in production. When testing expiry flows, use the generator’s “already expired” shortcut and watch the 401s. Deeper skew notes: JWT exp/nbf and clock skew.

Where the signing key lives

The most common JWT incident is not algorithm weakness — it is a hardcoded secret in a public repository. Treat the HMAC secret like a database password: environment-injected, rotated, minimum 256 bits of entropy. For RS/ES256, the private key belongs in a KMS or secret manager; the public key is the only part that ships. A quick hygiene check: search the codebase for the string your tokens are signed with — if it appears in source, rotate it now. This generator page briefly holds whatever secret you paste: test secrets only.

FAQ

Is the JWT Payload Encrypted?

No. JWT Payload is only Base64URL-encoded — anyone can decode and read it. Never store passwords, credit card numbers, or other sensitive data in JWTs. For encryption, use JWE (JSON Web Encryption).

What Happens When JWT Expires?

Use a Refresh Token mechanism. When the Access Token expires, use the Refresh Token to get a new Access Token without re-login. The generator’s Refresh (~7 days) and Access (~15 minutes) templates help rehearse that flow locally.

How Do You Immediately Invalidate a JWT?

Standard JWTs cannot be immediately invalidated (by design — stateless). Solutions: maintain a blacklist (add revoked JWTs to a blocklist), or use short expiration times to reduce the risk window.

Why doesn’t the generator mint RS256?

Asymmetric issuance needs a private key; holding a production private key in a browser tab is a worse risk than a test HMAC secret. For asymmetric integration tests, mint with a server-side test keypair, then inspect claims in the JWT Decoder.

Implementation notes

The FAQ's suggestion to take a freshly minted token to the decoder and inspect the claims is not politeness: the decoder supports a /en/tools/jwt-decoder?token=... deep link, so tools like api-tester can jump over with the token in hand. The deep-link parameter is read once at mount, so it never forms a two-writer race with the user's subsequent input.

This guide is part of the ToolVault toolkit. More developer tools at the homepage.