Hash Type Identifier

A stored hash often arrives without the database schema, application version, or migration notes that explain it. The visible string may still carry useful clues: a scheme marker, a tagged wrapper, an encoded alphabet, a fixed length, or embedded cost and salt fields.

Those clues do not all deserve equal confidence. A self-describing password string such as bcrypt or Argon2 names its family and carries parameters needed by a verifier. A bare hexadecimal digest usually does not. Thirty-two hex characters can fit MD5, MD4, or NTLM, while sixty-four can fit SHA-256 or SHA3-256. Length narrows possibilities but rarely proves identity.

Format identification is triage. It can route a record toward the right verifier or reveal a damaged copy, but it does not recover the original value, test a password, prove where a string came from, or rate the security of the surrounding system. Even a confidently labeled password hash may use weak parameters or belong to an account that needs a broader migration review.

Credential hashes remain sensitive because an attacker can test guesses offline. Keep source context private, avoid putting real values in tickets or public examples, and preserve the complete marker, salt, and parameter fields when a legitimate verifier needs them.

How to Use This Tool:

Classify one value per line, keeping the original export available until every cleanup and ambiguity decision is reconciled.

1. Paste values into Hash values or load a local TXT, LOG, or CSV file up to 1 MiB.
2. Choose Smart cleanup for copied assignments or log lines. It can remove a short leading label and extract one supported token. Choose Exact lines when surrounding labels or wrappers are evidence; matching outer quotes and surrounding whitespace are still removed.
3. Use Collapse normalized duplicates for an inventory of unique values. Keep every line when repetition or original row count matters.
4. Read the Identification ledger from the confidence label through the evidence and next action. A table filter changes only visible rows, not the summary counts or underlying classifications.
5. Send strong candidates to the matching verifier. Resolve ambiguous and probable rows with the source system, field meaning, software version, or trusted migration documentation.

Interpreting Results:

• Strong signal means an explicit prefix, tag, and complete structural pattern matched a supported format.
• Pattern match means a length-and-alphabet rule produced one candidate. It is still weaker than a self-describing marker.
• Ambiguous overlap means several families share the visible shape. Do not choose the first name in the list.
• Cleanup likely means normalization changed the line without finding a supported format, or the value appears truncated, incompletely padded, or wrapped in source text.
• Unknown format means no supported explicit or encoded-length rule matched. It does not prove the value is invalid or is not a hash.

Technical Details:

Classification examines syntax only. Explicit rules run before generic length rules, so a complete tagged or modular record is not reduced to its payload length. Matching is deterministic and does not hash input, decode passwords, contact a verifier, or query an external database.

Transformation Core

Each non-empty line is trimmed and matching outer quotes are removed. Smart mode may then remove one short assignment label and extract exactly one supported embedded token. Duplicate collapse keeps the first row for each normalized value. The retained token moves through explicit-format rules, then hex or Base64 length rules, and finally the cleanup-or-unknown decision.

1. Normalize the line and record whether cleanup changed it.
2. Test complete explicit structures and stop there when one matches.
3. Otherwise test hexadecimal or padded Base64 length mappings.
4. Assign strong, probable, ambiguous, cleanup, or unknown status from the resulting candidate count and cleanup evidence.

Rule Core

Explicit markers provide the strongest supported evidence. The groups below summarize the complete explicit rule set without treating the marker alone as proof.

Bare hexadecimal and Base64 values use the following candidate map. A row with several names becomes Ambiguous overlap; a row with one name becomes Pattern match.

The result filter is presentation-only. Strong and probable, ambiguous, and attention views use the same retained rows and do not recalculate counts. This preserves one classification result while allowing a narrower handoff.

Privacy and Security Notes:

Classification and local file reading happen in the browser. No password verification or remote lookup is performed. Exported CSV, JSON, and document files can contain the normalized hash values, so protect them like the original source.

• Do not paste plaintext passwords, authentication tokens, private keys, or unrelated log secrets.
• A format label says nothing by itself about cost settings, salt quality, account security, or whether a record is still active.
• Use a trusted, format-aware verifier for legitimate migration or authentication work; never convert a length-only guess into a destructive migration decision.

References:

• RFC 9106: Argon2 Memory-Hard Function, Internet Research Task Force, September 2021.
• NIST Special Publication 800-63B: Authentication and Authenticator Management, National Institute of Standards and Technology.