What the Token Strength Analyzer Does
The Token Strength Analyzer estimates how much entropy — genuine unpredictability — a token string carries, and whether that is enough. Paste any credential-shaped string (an API key, a session ID, a share link slug) and the output panel reports three numbers: the token's length in bytes, its count of distinct symbols, and an estimated entropy in bits, followed by a verdict line — ✓ Reasonable entropy. or ⚠ Consider a longer or higher-entropy token. at the 80-bit threshold.
The estimate is built on one honest, conservative assumption: that an attacker knows your token's alphabet and nothing else, so each distinct symbol could be any of the characters that actually appear. The formula is entropy = bytes × log2(distinct symbols). A 32-byte hex key with all 16 hex digits present scores 32 × 4 = 128 bits — comfortable. A 32-byte key that only ever uses 0-9 scores 32 × 3.32 ≈ 106 bits — still decent, but the drop shows you exactly where the weakness enters: repetition of a small character subset.
This is a
strength estimator for secret-looking strings, deliberately distinct from the
Password Strength Checker, which scores human-chosen passwords with composition heuristics. This tool's target is machine-generated credentials, where the questions are different: how random is the generator's output, and is the token long enough for the alphabet it uses.
How the Entropy Estimate Works
Entropy measures how many distinct possibilities a token could have been, expressed in bits. Each additional bit doubles the search space; a token with n bits of entropy has 2ⁿ possibilities, and at 80 bits the space is large enough that brute force is impractical at almost any budget. The tool estimates the entropy of what you pasted from its two measurable properties.
First, length in bytes — computed on the UTF-8 encoding, not the character count, so multi-byte characters are weighted honestly. Second, the number of distinct symbols — how many different characters actually appear in the string. The estimate multiplies the two: each byte position is assumed to be an independent draw from an alphabet as large as the distinct-symbol count, contributing log2(distinct) bits per position.
The estimate's known shape matters for reading it. Because it derives the alphabet purely from what it observes, it cannot see structure a real attacker could exploit: a token like aaaa...1 with one distinct variation looks strong in aggregate but is trivially enumerable. The estimate is a floor for garbage and a ceiling for praise — read it alongside how the token was generated.
The 80-bit verdict threshold is a pragmatic reference point, not a standard: 80 bits is the level at which exhaustive search stops being a plausible attack for a well-resourced adversary, and well below the 128-bit territory of properly generated modern keys. A 32-byte token drawn uniformly from even a 64-symbol alphabet reaches 192 bits, so anything generated by a reputable key generator clears the bar with room to spare. Tokens that fail the check are usually short (shorter than 10 bytes), or drawn from tiny alphabets — numeric OTP strings, for instance, at ~3.3 bits per digit.
What the tool does not do is network anything, or judge the token's format. A base64 string, a hex string, a JWT, a UUID — all are just character sequences here. Format-specific questions (is this a valid UUID, is this JWT signed) belong to their own tools; this one answers only: how unpredictable is this string, as a string.
Using the Token Strength Analyzer
- Step 1 — Paste the token. The full credential string, exactly as issued — no trimming, no reformatting. Whitespace counts as a symbol and changes the numbers.
- Step 2 — Run the transform. No options. The output is three metrics and a verdict.
- Step 3 — Read the numbers in order. Length tells you the raw material; distinct symbols tells you the alphabet the estimate assumes; entropy tells you the search space. A low distinct-symbol count is the usual story behind a weak verdict — hex output that only used digits, a base64 token drawn from a tiny alphabet.
- Step 4 — Compare candidates, not absolutes. The verdict's threshold is fixed, but the most productive use is comparative: two tokens from different generators, or the same generator with different length settings, differ meaningfully in estimated entropy even when both "pass."
- Step 5 — Fix weak tokens at the generator. The tool diagnoses; it does not repair. A weak result means generating a new token with more bytes or a larger alphabet — the Random API Key Generator does exactly that, with configurable byte counts and output encodings.
Common Use Cases
Auditing your key generator's output. Sample a handful of tokens from whatever generates your API keys and run them here. The distinct-symbol metric is a quick smoke test for broken generators — a hex generator that only ever emits digits or repeats a narrow range has a visible signature in these numbers.
Assessing share-link slugs and reference IDs. Unguessability is the only access control on many a share-by-URL feature. Paste the slug and the entropy number tells you whether the URL is discoverable by enumeration or genuinely private-by-randomness.
Sizing tokens for a security policy. If your organisation's standard demands ≥128-bit tokens, this tool converts that requirement into concrete length guidance for any alphabet: 16 bytes of full hex is 128 bits; 22 characters of full base64 likewise.
Worked Example
Paste a strong token first — 32 random bytes rendered as hex:
199c9e5e3acb7404875592ddca8710e11c705d44a9e21bd2977e50ac432ef34e
The report reads:
Length: 64 bytes
Distinct symbols: 16
Estimated entropy: ~256.0 bits
✓ Reasonable entropy.
Sixteen distinct symbols — every hex digit — yields log2(16) = 4 bits per byte, and 64 bytes of it is 256 bits. That is a properly generated key's signature: high distinct-symbol count across a long string. (The estimate reads UTF-8 bytes, so each ASCII hex character is one byte — the numbers align with the token's character length.)
Now the cautionary contrast — a 6-digit numeric OTP:
482913
reports 6 bytes, 6 distinct symbols, and roughly 6 × log2(6) ≈ 15.5 bits — a ⚠ verdict with room to spare. Fifteen bits is a search space of about 32,000, enumerable in milliseconds. The tool is not saying the OTP is wrong — OTPs are constrained by design to human typeability — it is saying this string must not be the only barrier protecting anything. Both readings, side by side, are the tool doing its job.
Tips and Common Mistakes
- High entropy is necessary, not sufficient. A token can score beautifully and still be worthless if it is transmitted insecurely, logged, or never expires. Entropy measures one axis — unguessability — of a credential's real security.
- The estimate cannot see structure. Patterns like sequential runs, embedded timestamps, or a constant prefix reduce practical strength below the estimate. Read the number alongside how the token is generated; trust neither alone.
- Distinct symbols is the metric to watch. Two tokens of equal length differ enormously if one uses 16 distinct characters and the other 64 — a 2× difference in bits per position. A weak verdict usually traces here first.
- Paste exactly what was issued. Trimming, re-encoding (hex → base64), or adding quotes changes the metrics. The question is the token as it exists, not the token you wish you had.
- Do not paste real credentials you cannot rotate. The tool is local-only — nothing transmits — but the standing rule holds everywhere: prefer expired or test tokens, and know how to rotate whatever you paste.
Frequently Asked Questions
What entropy target should I aim for?
80 bits — the tool's verdict threshold — is the practical floor below which exhaustive enumeration becomes plausible for a resourced attacker. 128 bits is the modern default target for anything generated to be a secret, and properly generated 32-byte keys reach 128–256 bits comfortably. Match the target to consequence: a share-link slug and an API signing key do not need the same bar, but nothing user-facing should sit below the tool's threshold.Why does my long token still score poorly?
Almost always alphabet, not length. Entropy is length × log2(distinct symbols), so a 64-byte token drawn from 2 distinct characters scores 64 bits — weaker than a 16-byte token using all 16 hex digits (64 bits) — while a 16-character token with 6 distinct symbols scores ~41 bits. When the verdict is weak, the distinct-symbol line is where the explanation lives.How is this different from the Password Strength Checker?
The password tool scores human-chosen passwords: composition rules (upper, lower, digits, symbols), dictionary checks, pattern detection — because human choices are the weakness there. This tool scores machine-generated strings on unguessability alone, via entropy. A random hex string and a 20-character password can score differently in each tool, correctly, because they answer different questions.Does it send my token anywhere or store it?
No — the computation is character counting and a logarithm, performed in the page; nothing transmits and nothing persists past the tab. The standing habit still applies: prefer test tokens, and know the rotation story for anything real you paste anywhere.Can it tell me whether a token is leaked or compromised?
No — entropy has no opinion on where a token has travelled. A perfect 256-bit token that appeared in a log is compromised regardless of its strength. For exposure questions, check your issuer's revocation and audit tooling; for strength questions, this tool. The two axes are independent, and this tool is explicit about owning only one.Related Tools
Random API Key Generator produces tokens that score well here, with configurable byte counts and encodings;
Password Strength Checker covers the human-password side with composition and pattern heuristics;
UUID Generator generates identifiers whose unguessability varies by version — v4 scores high, sequential versions do not;
Hash Generator covers integrity rather than secrecy; and
HMAC Generator shows the keyed-hash construction that turns any of these into authenticated credentials.