| Signal | Rows | Basis |
|---|---|---|
| {{ item.label }} | {{ item.count }} | {{ item.basis }} |
| Input | Candidates | Why ambiguous | Next step |
|---|---|---|---|
| {{ row.normalizedHash }} | {{ row.candidateSummary }} | {{ row.evidence }} | {{ row.nextStep }} |
| Input | Status | Flag | Next step |
|---|---|---|---|
| {{ row.rawLine }} | {{ row.statusLabel }} | {{ row.evidence }} | {{ row.nextStep }} |
| # | Input | Normalized | Status | Top signal | Candidates | Evidence | Next step | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ index + 1 }} | {{ row.rawLine }} | {{ row.normalizedHash }} | {{ row.statusLabel }} | {{ row.topSignal }} | {{ row.candidateSummary }} | {{ row.evidence }} | {{ row.nextStep }} | |
| No rows match the current filter. | ||||||||
| # | When | Items | Rows | Strong | Ambiguous | Attention | Settings | Actions |
|---|---|---|---|---|---|---|---|---|
| {{ index + 1 }} | {{ formatWhen(item.ts) }} | {{ item.items }} | {{ item.rows }} | {{ item.strong }} | {{ item.ambiguous }} | {{ item.unknown }} | {{ historySettingsText(item) }} |
|
| No snapshots yet. Paste a value above and the tool can keep a local trail when Save history is on. | ||||||||
Hash strings and password-hash encodings often carry visible clues about what they are. Fixed hex length, Base64 padding, and modular-crypt prefixes can all narrow the list of plausible families before you know anything about the system that produced the value.
This identifier performs that first-pass classification from the text you paste. It can flag familiar digest families such as MD5 and the SHA variants, structured password-hash strings such as bcrypt, Argon2, scrypt-crypt, and PBKDF2, plus LDAP-style {SHA} and {SSHA} entries and short Base64 fingerprints.
That makes the page useful during migrations, forensic note-taking, breach cleanup, and log review. A quick read of likely candidates tells you which verifiers or storage formats deserve further investigation.
The tool is intentionally conservative about certainty. It does not recompute a digest, test a password, or inspect the originating application, so overlapping formats stay overlapping formats. A 40-character hex string can honestly fit both SHA-1 and RIPEMD-160, and the output shows both rather than pretending the string carries more evidence than it does.
Everything runs in the browser. The current text can also persist in history snapshots and may be mirrored into the shareable h URL parameter, so sensitive values still deserve careful handling even though no server request is made.
For a single string, the summary box shows a Top Match so you can glance at a likely family before opening the table. For batch work, the same space switches to counts: total entered lines, unique values after de-duplication, how many unique rows matched at least one pattern, and how many remained unknown.
The Hash Results tab is the main working view. Each row keeps the original string and lists every candidate family that matched its visible structure. The History tab is useful when you are comparing exports or rechecking a prior batch, because snapshots are saved automatically as you type and can be restored later.
If you need something machine-readable, the JSON tab exposes the run as a payload with input counts, per-hash candidate lists, and summary totals. CSV and DOCX exports are available for both the current result table and the history table.
Unknown rows are not necessarily bad rows. They simply mean none of the built-in signatures matched exactly. That can happen because the value is truncated, padded differently, wrapped in a label, or belongs to a format this page does not try to recognize.
The page works by shape, not by cryptanalysis. Some digests are recognizable because their byte length maps cleanly to a fixed-length hexadecimal string. Others expose themselves through a prefix that names the algorithm family and sometimes embeds cost or salt metadata, as happens with modular-crypt password hashes.
This tool turns those visible features into regular-expression tests. A match means "this string fits the expected structure," not "this string has been proven to originate from that algorithm." That distinction is most important for plain hex digests, where several families can share the same length and alphabet.
Batch behavior is deliberately normalized. Blank lines are dropped, duplicate non-empty lines are collapsed before analysis, and the results array preserves one row per unique string. The summary area still remembers how many input lines were entered, which helps you tell the difference between a repeated value and a genuinely varied dataset.
Local state is part of the design. The page stores up to 20 recent snapshots in browser storage, each with the raw text plus compact counts. It also mirrors the current textarea into a Base64-encoded h URL parameter, capped at 2000 characters after encoding, so short runs can be shared or reopened directly.
| Family group | Examples surfaced by the page | Primary visible cue |
|---|---|---|
| Fixed-length hexadecimal digests | CRC-32, MD5, SHA-1, RIPEMD-160, SHA-224, SHA-256, SHA-384, SHA-512 | Exact hexadecimal length, case-insensitive. |
| NTLM heuristic | NTLM | A 32-hex string plus at least one uppercase A to F. |
| Modular-crypt style strings | bcrypt, Argon2, scrypt-crypt, PBKDF2 | A leading algorithm marker such as $2b$, $argon2id$, $7$, or $pbkdf2-sha256$. |
| LDAP scheme-tag formats | {SHA}, {SSHA} |
A literal scheme tag followed by a Base64 payload. |
| Short Base64 digest encodings | Base64-MD5, Base64-SHA1 | Exact Base64 length and required padding characters. |
The most common collisions come from families that share a string length and alphabet. A 32-character hexadecimal string looks like MD5, but this page can also label it NTLM when uppercase hexadecimal letters are present. A 40-character hexadecimal string is surfaced as both SHA-1 and RIPEMD-160 because shape alone cannot separate them.
Structured password-hash strings are less ambiguous because the prefix usually names the family directly. Even there, the page still stops short of semantic validation. It does not verify that a bcrypt cost is appropriate, that an Argon2 parameter set is complete, or that a PBKDF2 string can actually be verified by a particular library.
| Surface | Contents | Practical use |
|---|---|---|
| Hash Results | One row per unique non-empty input string, with a candidate list for each row. | The fastest way to review structure, ambiguity, and unknown rows. |
| Summary box | Top Match for one unique row, or Items / Unique / With matches / Unknown counts for batches. | Quick triage before exporting or drilling into the table. |
| JSON tab | Input counts, result rows, matched count, and unknown count in a pretty-printed payload. | Structured capture for notes or comparisons. |
| Lookup History | Timestamped snapshots with item counts, unique counts, matched counts, and the original pasted text. | Reopening prior runs or preserving a local review trail. |
| Share parameter | Base64-encoded textarea content mirrored into h, truncated to 2000 characters after encoding. |
Lightweight sharing of smaller batches. |
This page never computes or verifies a digest. Every conclusion comes from the visible format alone. That is why it can be very helpful for sorting and documentation, while still being the wrong tool for proving integrity, testing passwords, or rating cryptographic strength.
If the table ends with No parsable items. or a row has no candidate badges, clean up the pasted text first so each line contains just one value.
.txt file with one value per line.Top Match; for larger sets you will see batch counts instead.Hash Results and review the candidate badges for each unique row rather than relying only on the summary.Copy CSV, Download CSV, or Export DOCX when you need a portable worksheet of the current result table.JSON tab if you want the same run as a compact payload with counts and per-row candidates.Lookup History to restore, copy, or download a previous batch. Snapshots are saved automatically as the text changes.h parameter does not exceed the page's 2000-character cap.Prefer sample or scrubbed values whenever possible. Even though the page stays in the browser, production password hashes and other secrets can still be sensitive on the local machine where they were pasted.
The most important habit is to read candidate labels literally. They mean "matches this visible pattern," not "is definitely this algorithm." That is why some rows show multiple badges and why an empty candidate list is still useful rather than a software failure.
| Output cue | What it means | How to use it safely |
|---|---|---|
| Top Match | The first candidate listed for the first and only unique row. | Treat it as a convenience label, not a confidence score. Always open the table to see whether other candidates were also returned. |
| Multiple candidate badges | The string fits more than one recognized structure. | Use source-system context, prefix semantics, or a known verifier to resolve the ambiguity. |
| No candidate badges | No built-in pattern matched the string exactly. | Check for truncation, labels, missing Base64 padding, or an unsupported family. |
| Items versus Unique | Items counts non-empty input lines, while Unique counts distinct values after de-duplication. |
Use the difference to spot repeated values or duplicated rows in an export. |
| With matches versus Unknown | The batch summary reports how many unique rows matched at least one pattern and how many did not. | High unknown counts usually mean format cleanup is needed or the dataset includes unsupported families. |
A false-confidence warning is especially important for 32-hex and 40-hex strings. Uppercase 32-hex values can trigger both MD5 and NTLM labels, and 40-hex values are intentionally reported as both SHA-1 and RIPEMD-160. The remedy is not to pick one label by intuition, but to confirm the origin system, prefix convention, or verifier that produced the value.
For structured password hashes, the safest verification step is to inspect the visible prefix and then test the value with the library or application that is supposed to consume it. For plain digests, compare byte length, encoding, and case handling against the surrounding system before treating the row as settled.
5F4DCC3B5AA765D61D8327DEB882CF99 fits the MD5 length and alphabet exactly, but the uppercase hexadecimal letters also trigger the page's NTLM heuristic. The correct interpretation is not "the tool is confused." The correct interpretation is that the string shape alone does not settle the question, so you should use source context before choosing a family.
A value beginning with $2b$12$ is surfaced as bcrypt because the modular-crypt prefix and fixed payload length are much more specific than plain hexadecimal length rules. In practice, this is the kind of row where the page is most helpful for migration prep: it tells you quickly which verifier family to test next.
Suppose a pasted line is SHA256: e3b0c44298fc1c149afbf4c8996fb924... and the page returns no candidate badge. The issue may be formatting, not the underlying digest. Remove the label, keep only the raw value, and restore any missing characters or padding. If it still shows as unknown after cleanup, the string is probably truncated or outside the page's built-in pattern set.
No. It proves only that the string matches one or more known structural patterns. Real confirmation comes from the system that produced the value or from a verifier that can successfully consume it.
Because some families share the same visible format. The common examples are 32-hex strings and 40-hex strings. The page keeps all plausible candidates visible so you do not mistake a formatting clue for definitive proof.
No. The page analyzes text in the browser and makes no network requests during classification. The main privacy tradeoff is local persistence: history snapshots are stored in the browser, and short runs can be mirrored into the share URL parameter.
Top Match is only the first candidate in the result list for a single unique row. It is a convenience headline, not a ranking score. Open the table to see whether the page also returned other candidates for that same string.
Strip labels, comments, and extra punctuation so each line contains just one raw value. Then check for missing Base64 padding, accidental whitespace, or truncation. If nothing matches after cleanup, the value is probably outside the built-in pattern list.
Only if your handling policy allows it. The page stays in the browser, but sensitive values can still remain in local history snapshots or in the shared URL parameter until you clear them.
$2b$ or $argon2id$ and can embed parameters.