What this checks
For an HMAC-signed JWT (HS256, HS384, or HS512), the secret is the entire security of the token — anyone who knows it can forge a token with any claims they want. This tool checks a candidate secret against three independent things: whether it's long enough to meet the actual JWT specification, whether it's one of the extremely common default or example secrets that real attack tools try first, and a rough estimate of how much variety its characters contribute.
The length requirement is not just a best practice
RFC 7518 §3.2, the JSON Web Algorithms spec, states it in MUST-level language: "A key of the same size as the hash output (for instance, 256 bits for 'HS256') or larger MUST be used with this algorithm." That means a secret shorter than 32 bytes for HS256, 48 bytes for HS384, or 64 bytes for HS512 isn't just weak — it technically doesn't conform to the spec. The OWASP JWT Cheat Sheet echoes the same minimum and adds a separate floor: at least 160 bits of entropy, generated with a cryptographically secure random generator rather than typed as a passphrase.
Why the known-weak-secret check matters as much as length
A secret can be exactly 256 bits long and still be worthless if it's something an attacker would guess in the first few tries. Projects like Wallarm's jwt-secrets compiled thousands of real secrets found by scanning public GitHub repositories — placeholder values like your-256-bit-secret (the same default this site's own JWT Generator uses, since it's only ever building test tokens) end up hardcoded and shipped to production far more often than anyone intends. Tools like hashcat and jwt_tool run exactly these wordlists against a token's signature offline, with no rate limiting to stop them.
FAQ
Is my secret uploaded anywhere?
No — everything here runs entirely in your browser.
The "character variety" entropy estimate — how reliable is it?
It's a rough upper bound based on which character classes (lowercase, uppercase, digits, symbols) appear in the secret, the same style of estimate Password Generator uses. It can't tell the difference between a truly random string and a memorable phrase that happens to mix cases and add a digit — both can produce the same estimate while being very different in practice. Treat a low number as a real red flag, but don't treat a high number as proof of true randomness the way a CSPRNG-generated secret is.
What should I actually use as a JWT secret?
Bytes from a cryptographically secure random generator, sized to at least your algorithm's minimum — the "Generate a strong secret" button above does exactly that using the Web Crypto API's crypto.getRandomValues. Store it as a server-side environment variable or secret manager entry, never in source code.
I need to actually verify or build a token, not just check a secret
See JWT Signature Verifier to check a real token against this secret, or JWT Generator to sign a new test token with it.