Identificador de Hash

How a hash can be identified without reversing it

A cryptographic hash is a one-way function: it turns any input into a fixed-length fingerprint, and there is no way to run it backwards to recover the original. So when you stumble on a mysterious string in a database dump, a log file, or a config, you can't decode it — but you can often work out which algorithm produced it. That is what this tool does. It looks only at the visible structure of the string: its length, its character set, and any prefix the format reserves. From those clues it lists every known algorithm that could have produced a fingerprint of that exact shape. The entire check runs in your browser with simple pattern matching, so the hash you paste is never uploaded anywhere.

Length is the biggest clue

Most hashes are printed in hexadecimal, where each byte of output becomes two characters. So the character count tells you the output size directly. A 32-character hex string is 128 bits, a 40-character one is 160 bits, 64 is 256 bits, and 128 is 512 bits. The tool checks the trimmed string against the known length for each algorithm and only matches hex strings that contain solely the digits 0-9 and letters a-f.

This is why a single length usually yields several candidates rather than one answer. A bare 32-character hex string is genuinely ambiguous between MD5, NTLM, and RIPEMD-128 — they all produce 128-bit output and there is no way to tell them apart from the digest alone.

Prefixes resolve the ambiguity

Some formats embed a marker that removes all doubt. The Modular Crypt Format, used in Unix password files, starts with a dollar-delimited identifier. The tool recognises these prefixes and requires both the prefix and the exact length to match:

• $2a$ / $2b$ — bcrypt, 60 characters, with the cost factor and salt baked in.
• $1$ — MD5-crypt, the obsolete legacy Unix scheme.
• $5$ — SHA-256-crypt.
• $6$ — SHA-512-crypt, the default in modern Linux /etc/shadow files.

When you see one of these, you don't have a plain digest — you have a full password-hash record that already contains its own salt. That is a feature, not a coincidence.

A worked example

Paste 5d41402abc4b2a76b9719d911017c592. It is 32 characters and all hex, so the tool reports candidates including MD5, NTLM, and RIPEMD-128, each shown with a security badge. MD5 is flagged "Not Secure" because it is cryptographically broken — collisions can be generated in seconds — and the result notes its typical uses (file checksums, legacy storage). To pin down which one you actually have, you need context the string can't give you: where it came from. A hash pulled from a Windows SAM database is almost certainly NTLM; the same length pulled from a file-integrity manifest is almost certainly MD5.

Practical tips and common mistakes

• Trim invisible characters. A trailing newline or space changes the length and breaks the match. The tool trims for you, but if you get "No matches," suspect a stray character or a truncated copy-paste.
• Identification is not cracking. Knowing a string is SHA-256 tells you nothing about the input that produced it. Recovering the original still requires brute force or a lookup table, and a properly salted hash defeats both.
• Salted and encoded hashes won't match. If a value has been Base64-encoded, concatenated with a salt, or stored in a custom format, its length won't line up with any standard digest and you'll see "No matches." That itself is information — it usually means a non-standard scheme.
• Same length, different algorithm. Never assume a 64-character hex string is SHA-256; it could equally be SHA3-256 or BLAKE2b-256. Use the surrounding system to decide.
• Checksums are not hashes. CRC32 and Adler-32 share the 8-character length but exist only to catch transmission errors. Never use them for security; they are trivial to forge.

Why "secure" labels matter

The tool marks each algorithm secure or not. MD5, SHA-1, MD4, NTLM, LM, and the CRC checksums are flagged insecure: they are either broken by collision attacks or were never designed to resist them. SHA-256, SHA-512, the SHA-3 family, bcrypt, and BLAKE2 are still trustworthy. If you discover that a system stores passwords as bare MD5 or SHA-1, treat that as a finding worth fixing — modern password storage should use an adaptive function like bcrypt that is deliberately slow and salted per record.