Hash Type Identifier

Introduction

Hash strings often reveal part of their identity before you verify them. A prefix such as $2b$ or $argon2id$, a directory scheme tag such as {SHA}, or a fixed digest length can narrow the field quickly when you are staring at copied values with no other context.

This page turns that structural reading into a practical first pass. You can paste one value per line or upload a plain-text list, and the tool will sort each entry into likely families such as crypt-style password hashes, LDAP-tagged values, common hex and Base64 digest lengths, several database authentication strings, Windows cached-credential formats, and a small set of checksum-like tokens.

That makes it useful in migrations, incident notes, log review, and breach cleanup. Before you try a verifier, rebuild a parser, or decide whether two exports belong to the same system, you usually need to know whether a token looks like a password hash, a plain digest, a directory value, or a platform-specific credential string.

The boundary matters just as much as the convenience. The page does not crack passwords, recompute digests, prove which application created a token, or rate cryptographic strength. It only asks whether the visible text matches one or more supported layouts. If two families share the same length and alphabet, both stay on the page because the string itself does not justify a stronger claim.

Routine analysis stays in the browser after the page loads. That helps keep the workflow local, but short runs can still be placed into a shareable link when you allow it, and history snapshots can be stored in the same browser. Real credential material still deserves careful handling on the machine where you inspect it.

Technical Details

The classifier works in layers. It starts by cleaning obvious wrappers, then looks for direct markers that strongly name a family, and only after that falls back to broad shape checks such as digest length and alphabet. Prefix-tagged values usually produce the clearest answer. Plain hex or Base64 strings are weaker evidence because many families can share the same visible size.

The cleanup step is deliberately modest. Both modes trim outer quotes. Smart cleanup goes further by stripping short labels like SHA256: or hash= when the remainder still looks hash-like, and it can pull out a single obvious token from copied surrounding text. Strict mode leaves those wrappers in place so you can see exactly what a raw export contains.

Those length rules explain why some rows land in overlap buckets. A 16-byte digest becomes 32 hex characters or 24 Base64 characters. A 20-byte digest becomes 40 hex characters or 28 Base64 characters. Once the encoding is stripped down to those sizes, the page can often say which families remain plausible, but it cannot always name a single winner without a prefix, a scheme tag, or outside system context.

Batch handling is also part of the interpretation. With duplicate collapse turned on, repeated normalized values are analyzed once, while the summary still remembers how many non-empty lines were entered. That makes it easier to distinguish a noisy export with many repeats from a dataset that truly contains many different token shapes.

Everyday Use & Decision Guide

Start with the summary box and the Triage Brief tab. For one analyzed row, the headline turns into a plain-language verdict such as Likely Family, Ambiguous Format, Cleanup Needed, or Unknown Format. For larger batches, the same area becomes a count-based overview so you can tell at a glance how many rows matched cleanly and how many still need attention.

The Lookup Table tab is the real working surface. It keeps the original line, the normalized token, a status badge, the top signal, every matched candidate, the reason behind that outcome, and a practical next step. The row filter is useful when you want to review only high-confidence rows, isolate overlaps, or work through the cleanup queue first.

Choose Smart cleanup when values come from tickets, log files, emails, or copied shell output. Choose Strict raw values when you are validating an export and need to know whether the token already stands on its own. The duplicate-collapse switch is similar: keep it on for noisy dumps that repeat the same value many times, and turn it off when every line is evidence and repetition matters.

The other tabs support documentation rather than discovery. Lookup History stores up to 20 local snapshots with the original text and the settings used for that run, which is useful when you are comparing several batches in one browser session. JSON exposes the same run as structured data with counts, recommendations, signals, row-level evidence, and current history entries.

• Use the page before password-migration work to separate crypt-style password hashes from plain digests and database-specific auth strings.
• Use it during incident review to explain why several tokens look alike but should still be handled by different verification workflows.
• Use it on mixed exports to split cleanly tagged rows from overlap rows before deeper analysis begins.
• Use local history, brief copy, CSV, DOCX, or JSON export when you need a review trail without retyping the same batch.

Step-by-Step Guide

1. Paste one candidate value per line or upload a plain-text list.
2. Pick Smart cleanup when the lines may include labels or copied wrapper text, or switch to Strict raw values when you want exact raw-token matching.
3. Decide whether duplicate normalized values should collapse into one analyzed row.
4. Read the summary box first, then open Triage Brief to see the run assessment, recommendation list, signal breakdown, ambiguous rows, and rows needing attention.
5. Open Lookup Table and use the row filter to focus on high-confidence rows, overlaps, or attention items.
6. Copy or export the brief, table, history, or JSON only after the cleanup mode and duplicate setting match the evidence you want to preserve.
7. Resolve every ambiguous or unknown row with outside context, a known verifier, or the originating system before treating the classification as final.

Interpreting Results

The most important habit is to read each label literally. A strong signal means the visible syntax is very specific. A pattern match means one supported layout fit cleanly. An overlap means the text fits more than one family. None of those labels mean the page has proven origin, cracked a password, or inspected anything beyond the text you supplied.

Prefix-tagged values deserve the most confidence because the family name is part of the token itself. That is why strings beginning with markers such as $2b$, $argon2id$, $pbkdf2-..., or directory tags like {SHA} usually sort cleanly. Plain 32-char or 40-char hex strings are much weaker evidence because length alone cannot separate several families that produce the same text shape.

The batch counts also carry meaning. A large difference between Non-empty lines and Analyzed rows usually means duplicate collapse removed repetition. A large cleanup or unknown count usually means the export needs preparation work before deeper verification starts. That is a workflow clue, not just a presentation detail.

Worked Examples

Copied digest line with a label attached

A line such as SHA256: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 is a good fit for Smart cleanup. The label can be removed before matching, but the result still stays honest: a 64-char hex token remains an overlap between SHA-256 and SHA3-256 because the visible size fits both families.

bcrypt string with an embedded cost field

A value beginning with $2b$12$ is a strong signal because the family marker, work-factor field, and fixed payload shape all line up. That is the kind of row you can usually route straight into a bcrypt-capable verifier without first debating whether it might be a plain digest.

Forty-character hex with no prefix

A bare token like da39a3ee5e6b4b0d3255bfef95601890afd80709 stays ambiguous by design. The page will surface SHA-1 and RIPEMD-160 together because both are commonly rendered as 40 hex characters. The safest next step is to check the source application or verification workflow, not to pick one label because it feels more familiar.

Base64-looking value with missing padding

A copied token that looks Base64-like but has the wrong length or missing = padding will usually land in Cleanup needed. That is helpful because the problem is often formatting, not the absence of a real digest. Restore the full token first, then rerun the check before treating it as unsupported.

FAQ:

Glossary:

Digest

A fixed-size output from a hash function, often shown as hexadecimal or Base64 text.

Password hash

A stored value used to verify a password later, usually with a salt and a cost or iteration setting.

Modular crypt string

A password-hash text format that uses $-separated fields to expose family and parameter information.

Scheme tag

A leading label such as {SHA} that tells a directory client how to interpret the rest of the value.

Salt

Extra data mixed into password hashing so identical passwords do not always produce identical stored strings.

Ambiguous overlap

A case where one token shape fits more than one supported family and the text alone cannot settle the choice.

References:

• RFC 4648, The Base16, Base32, and Base64 Data Encodings, IETF.
• RFC 1321, The MD5 Message-Digest Algorithm, IETF.
• FIPS PUB 180-4, Secure Hash Standard, National Institute of Standards and Technology.
• RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1, IETF.
• RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications, IETF.
• bcrypt(3), OpenBSD manual pages.
• RFC 2307, An Approach for Using LDAP as a Network Information Service, IETF.