JWT Secret Generator

This JWT secret generator produces signing keys that satisfy the RFC 7518 minimum for HS256, HS384 and HS512. Everything is generated in your browser and nothing is transmitted.

What is a JWT secret?

A JWT secret is the key used to sign and verify JSON Web Tokens with an HMAC algorithm. It proves a token was issued by you and has not been altered since — it does not encrypt anything, and it never travels with the token.

Where the secret fits in a JWT

A token has three dot-separated parts. The first two are Base64URL-encoded JSON that anyone can decode; the third is a signature computed with the value a JWT secret generator gives you.

This surprises people regularly: a JWT is signed, not encrypted. Putting anything confidential in the payload exposes it to whoever holds the token.

The secret never travels with the token

Signing and verifying both happen on your server. A browser or mobile client receives tokens but must never receive the output of your JWT secret generator.

With HS256 the same value does both jobs, so anyone who can verify a token can also forge one. That symmetry is why a leaked signing secret is an authentication bypass, not just an information leak.

How long must a JWT secret be?

Unlike most keys, this is not a judgement call. The algorithm fixes the minimum, and a JWT secret generator that lets you go below it is producing invalid configurations.

The rule in RFC 7518

Section 3.2 of the specification is explicit:"A key of the same size as the hash output (for instance, 256 bits for HS256) or larger MUST be used with this algorithm."

MUST, not SHOULD. A 128-bit HS256 key is not a weaker choice but a non-compliant one, which is why this JWT secret generator removes such sizes from the options entirely.

HS256, HS384 and HS512

The number in the name is the hash size, and therefore the minimum key size: HS256 uses SHA-256 and needs 256 bits, HS512 uses SHA-512 and needs 512.

HS256 is the right default for almost every application, and it is where this JWT secret generator opens. The longer variants exist for systems that mandate a specific hash, not because HS256 is insufficient.

Why a longer key is allowed but rarely needed

The specification permits "or larger", so a 512-bit key with HS256 is valid. It also gains you nothing measurable, because HMAC caps effective strength at the hash size.

Reach for a longer key when a compliance requirement names one. Otherwise the algorithm minimum is the correct answer, and a JWT secret generator should default to it.

Using the secret in your stack

Whichever library you use, the pattern is the same: take the value from the JWT secret generator, put it in an environment variable, and pass it in at signing time. Never commit it, and never ship it to a client.

import jwt from 'jsonwebtoken';

const secret = process.env.JWT_SECRET; // kR8vN2pQ7wZ4mT6yB1xC3nH5...

const token = jwt.sign({ sub: '123' }, secret, {
  algorithm: 'HS256',
  expiresIn: '15m',
});

import os, jwt

secret = os.environ["JWT_SECRET"]  # kR8vN2pQ7wZ4mT6yB1xC3nH5...

token = jwt.encode(
    {"sub": "123"},
    secret,
    algorithm="HS256",
)

use Firebase\JWT\JWT;

$secret = getenv('JWT_SECRET'); // kR8vN2pQ7wZ4mT6yB1xC3nH5...

$token = JWT::encode(
    ['sub' => '123'],
    $secret,
    'HS256'
);

Each example reads from the environment rather than embedding the secret. A key pasted into source is a key in your git history, however carefully the JWT secret generator produced it.

JWT attacks a strong secret does not stop

A compliant key from any JWT secret generator closes off brute force. Several well-known JWT failures have nothing to do with key strength.

The alg=none attack

The JWT specification includes an algorithm called none, meaning "unsigned". An attacker edits the header to {"alg":"none"}, strips the signature, and sends the token.

A verifier that trusts the header's algorithm accepts it. Your key was never involved, so no JWT secret generator could have prevented it.

Algorithm confusion

A system using RS256 verifies with a public key. If an attacker re-signs a token with HS256 using that public key as the HMAC secret, a naive verifier will validate it — the public key was never meant to be secret.

What actually protects you

Pin the expected algorithm in your verification call rather than reading it from the token. Every mainstream library supports this, and most now require it — a step no JWT secret generator can take for you.

Validate exp, and check iss and aud if you issue tokens for more than one audience. A strong secret is necessary, not sufficient.

Storing and rotating a JWT secret

One secret per environment

Staging must not be able to mint tokens that production accepts. Run this JWT secret generator once per environment and keep the values apart.

Rotating without logging everyone out

Changing the secret invalidates every outstanding token at once. To avoid that, have your verifier accept a list of keys while signing only with the newest one your JWT secret generator produced.

Add the new key, wait for the old tokens to expire naturally, then drop the old key. Building this before an incident is far easier than during one.

What to do after a leak

Rotate immediately and accept the forced logout. A leaked HMAC secret lets an attacker mint a token for any user, so reach for the JWT secret generator before you finish investigating.

Short token lifetimes limit the damage window, which is the practical argument forexp values measured in minutes rather than weeks.

Frequently asked questions

More free generators

Every generator here runs locally in your browser, with no account and no limits. Where this JWT secret generator fixes the length for you, the secret key generator lets you choose it freely.