Skip to main content
Yoryantra
Home/Tools
← Back to Tools

JWT Secret Strength Checker

Check HMAC JWT secret bytes against JWA minimums and obvious guessable patterns.

The value is not trimmed or normalized. For UTF-8 mode, spaces and line endings are part of the key bytes.

A signing secret is a credential. Prefer a disposable test value here. If you must examine a production key, keep the page and any screenshots private and leave masking enabled.

Tell the checker how your application uses the value

JWA requires HMAC keys at least as large as the hash output: 32 bytes for HS256, 48 for HS384, and 64 for HS512. Those byte floors do not become optional in a “relaxed” mode.

Output

JWT secret assessment will appear here.
Analysis stays in this browser. The page counts or decodes the value you provide and never needs to send the secret to a verification service.

HMAC security starts with the actual key bytes

HS256, HS384, and HS512 are symmetric JWT signing algorithms: the same secret is used to create and verify the MAC. RFC 7518 requires a key at least as large as the corresponding hash output—256, 384, or 512 bits.

Character count is not the standard. A 32-character ASCII value is 32 bytes, while 32 non-ASCII characters may occupy more UTF-8 bytes. Encoded strings add another wrinkle because an application may use the visible characters directly or decode them into bytes first.

Meeting the byte floor does not make a guessable phrase strong

A long project name, repeated character, leaked environment value, or familiar placeholder can still be a poor signing key. Anyone who has a valid HMAC-signed token can test candidate secrets offline, so predictable text deserves different treatment from uniformly random bytes.

That is why the result separates the standards-based byte check from local pattern checks instead of turning both into one invented “entropy score.”

Raw text, hex, and Base64 are not interchangeable

UTF-8 text

The exact entered text is encoded as UTF-8. Leading, trailing, and internal whitespace remain part of the key.

Encoded bytes

Hex, Base64, or Base64URL mode decodes the representation first. Choose one of these only when your application does the same.

A safer way to create and rotate HMAC JWT keys

  1. Generate the required number of random bytes with a cryptographically secure random source.
  2. Store the key in a secret manager or another credential store rather than source code.
  3. Configure the verifier to accept only the HMAC algorithm you intentionally deploy.
  4. Plan rotation so old tokens can age out without leaving one secret active indefinitely.
  5. If a key appears in logs, source control, chat, or screenshots, treat the exposure separately from its measured strength.

Where the requirements come from

RFC 7518 defines HS256, HS384, and HS512 and requires keys of at least 256, 384, and 512 bits respectively. RFC 8725 adds JWT deployment guidance, including algorithm verification and key-management cautions.

References: RFC 7518 §3.2 and RFC 8725.

Limits of a pasted-secret check

A single visible value cannot prove how it was generated, whether copies exist elsewhere, whether it is reused, or whether your verifier handles algorithms safely. “No obvious weakness” therefore means only that the selected byte requirement and the checks on this page did not find a problem.