JWT Secret Validator

How to validate a JWT secret

1. 1. Paste the secret string exactly as your app uses it — no quotes, no trailing spaces.
2. 2. Check the entropy figure. HS256 needs ≥ 256 bits, HS384 ≥ 384 bits, HS512 ≥ 512 bits.
3. 3. If any check fails, regenerate — never patch a weak secret by appending characters.
4. 4. Store the new value in a secrets manager (AWS Secrets Manager, Doppler, 1Password) and rotate on a schedule.

Reference: strong vs weak secrets

my-super-secret
password123
company-name-2024

# Node.js
require("crypto").randomBytes(64).toString("hex")

# OpenSSL
openssl rand -base64 64

Generating strong secrets in code

import { randomBytes } from "crypto";

const secret = randomBytes(64).toString("base64");
console.log(secret);

import secrets

secret = secrets.token_urlsafe(64)
print(secret)

import (
  "crypto/rand"
  "encoding/base64"
)

b := make([]byte, 64)
rand.Read(b)
secret := base64.RawURLEncoding.EncodeToString(b)

Related tools

Don't have a secret to test yet? Create a cryptographically random one with the JWT secret generator, or browse different formats and lengths on the generator variants page. Once you've settled on a secret, sign a real payload with it in the JWT encoder, then confirm the resulting token decodes as expected in the JWT decoder. If you're new to JWTs, What is a JWT? explains why the signing key matters so much for security. We also cover secret-rotation strategies and real incident write-ups on the blog, and answer more general questions on the FAQ page.

What is a JWT secret validator?

A JWT secret validator measures how resistant a signing key is to guessing and brute-force attacks before you ever use it to sign a real token. Unlike the decoder and encoder, which operate on the token itself, this tool operates purely on the key string that HMAC algorithms (HS256, HS384, HS512) use to compute signatures. Because HMAC security is only as strong as its key, a validator like this one exists to catch the single most common JWT vulnerability in the wild: developers hard-coding short, guessable, or default strings (like "secret" or a company name) as their production signing key. Running your candidate secret through entropy and composition checks here takes seconds and can prevent a trivially brute-forceable authentication system.

How the strength check works

1. 1. Character frequency analysis. The tool counts how often each distinct character appears in your input string.
2. 2. Shannon entropy per character. Using H = -Σ p(x) log₂ p(x) over the observed character distribution, it estimates the average information content (in bits) contributed by each character.
3. 3. Multiply by length. Total estimated entropy is roughly H × length, giving a bit-count comparable to key-strength recommendations (128, 256, 384, 512 bits).
4. 4. Composition checks. Separately, the tool flags whether the string mixes upper/lowercase, digits, and symbols, and whether it meets minimum lengths (32 / 64 characters) commonly recommended for HS256/HS512.
5. 5. Label and score. The combined bit estimate maps to a strength label (Weak → Excellent) and a visual score bar.

Worked example

Paste my-super-secret and you'll see roughly 60-70 bits of entropy — it fails the 32-character check, fails the 128-bit entropy check, and has no digits or symbols. Compare that to a key generated with openssl rand -base64 64, something like K7f3+9zQ1c/Xy8pR2mNw... (88 Base64 characters representing 64 random bytes) — this passes every check, comfortably clears 512 bits of estimated entropy, and is exactly the kind of key HS512 is designed to use. The practical takeaway: length alone isn't enough (repeating a weak pattern 40 times is still weak), and true randomness from a CSPRNG is what the entropy score is really rewarding.

Common mistakes with JWT secrets

• Using a dictionary word, product name, or company name as the secret — these are the first things checked by automated JWT-cracking tools like hashcat with a wordlist.
• Copying an example secret from documentation (e.g. "your-256-bit-secret") straight into production — these strings are public and assumed compromised.
• Committing the secret to source control instead of an environment variable or secrets manager, where it can leak through git history indefinitely.
• Padding a weak base string with predictable suffixes ("secret123!", "secret2024") — this barely raises entropy because the pattern is still guessable.
• Using the same secret across development, staging, and production — a leak in a lower environment then compromises production authentication too.

Security notes

This validator processes everything locally in your browser and never transmits what you type, but you should still avoid pasting an actual production secret into any third-party tool as a matter of operational hygiene — test with a freshly generated, disposable value of the same length and character set instead. Entropy estimation is a useful heuristic, not a formal proof of security; the real guarantee comes from generating keys with a cryptographically secure random number generator (Web Crypto's getRandomValues, Node's crypto.randomBytes, or openssl rand) rather than from typing something that merely looks random. Once you've generated a strong secret, keep it out of logs, error messages, and client-side bundles — a JWT signing key belongs in server-side configuration only.

JWT Validator FAQ

Related tools

Recent articles

Guides on JWT secrets, signing algorithms, and token security.