The hash type identifier above takes a hash string of unknown origin and tells you which algorithms and storage formats produce a value of that shape. It works from three signals only: the number of characters, the alphabet those characters are drawn from, and any structural prefix such as $2b$ or {SSHA}. That is genuinely all the information a bare hash contains. The analysis happens as local JavaScript in your browser, and nothing you paste is transmitted, stored or logged anywhere.
Arb Digital publishes this alongside its other free developer utilities because identifying a hash format is a routine task during a migration, an audit, or an incident, and it is oddly hard to do quickly from memory. Thirty-two hexadecimal characters could be MD5, MD4, NTLM or RIPEMD-128, and knowing which of those is plausible determines what happens next.
What This Hash Type Identifier Does — and What It Refuses to Do
Being precise about this matters. The tool classifies a format. It does not and cannot crack, reverse, decrypt or look up a hash. There is no wordlist on this page, no rainbow table, no lookup service, and no request to anything external. A cryptographic hash is a one-way function by design, so “decoding” one is not a feature that was left out — it is not a thing that exists. Anything that claims to decode a hash is either searching a database of previously seen values or guessing inputs and hashing them, and neither happens here.
What it does is straightforward pattern recognition. A 40-character hexadecimal string is a 160-bit digest, which narrows the field to SHA-1, RIPEMD-160 and a handful of application-specific formats. A string beginning with $2y$ is bcrypt regardless of anything else, because that prefix is part of the modular crypt format and encodes the algorithm and cost factor explicitly. The tool applies those rules and ranks the results.
Boundary worth stating: the hash generator produces digests from input you supply, which is the opposite direction of travel. This page starts with a digest whose origin is unknown.
How to Use It
- Paste the full string. Include any prefix, salt and separators. A bcrypt value stripped of its
$2b$12$header looks like an anonymous 53-character blob and identifies far worse. - Check the length reported. It is the strongest single signal, and a length that matches nothing usually means the value was truncated or has stray characters.
- Read the whole candidate list. Length alone rarely gives one answer, and the runners-up are frequently correct.
- Use context to choose. Where the value came from — a Windows domain, a WordPress database, a Linux shadow file — usually decides between candidates that a string comparison cannot.
- Treat the result as a hypothesis. Two algorithms with the same digest size are genuinely indistinguishable from the output alone.
How Identification Works
Hash outputs are fixed-length by construction, and a hexadecimal encoding uses two characters per byte. So the character count divides by two to give bytes, and by eight from there to give the digest size in bits. MD5 produces 128 bits, so 32 hexadecimal characters. RFC 1321, The MD5 Message-Digest Algorithm, specifies that 128-bit fingerprint directly. SHA-1 produces 160 bits, so 40 characters, as set out in RFC 3174, US Secure Hash Algorithm 1. The SHA-2 family gives 224, 256, 384 and 512 bits, or 56, 64, 96 and 128 hexadecimal characters, and is specified in NIST's FIPS 180-4, Secure Hash Standard.
Base64 encoding changes the arithmetic: three bytes become four characters, so a 160-bit digest becomes 28 characters including padding and a 256-bit digest becomes 44. If the string contains characters outside the hexadecimal alphabet but stays within A–Z, a–z, 0–9, plus and slash, base64 is the likely encoding and the tool switches to that interpretation.
Prefixed formats are the easy case and the most informative. The modular crypt format used in Unix password files puts the scheme in a dollar-delimited header: $1$ for MD5-crypt, $5$ for SHA-256-crypt, $6$ for SHA-512-crypt, $2a$, $2b$ or $2y$ for bcrypt with the cost factor following, and $argon2id$ for Argon2 with its memory, time and parallelism parameters spelled out. LDAP uses braces instead, as in {SSHA}. Application frameworks add their own, such as the pbkdf2_sha256$ form used by Django and the $P$ or $H$ of phpass, which is what older WordPress installations store.
Why Length Alone Can Never Give a Definite Answer
Two different algorithms with the same output size produce strings that are statistically identical. MD5, MD4 and RIPEMD-128 all emit 128 bits of essentially uniform random-looking hexadecimal. Nothing in the digest distinguishes them, because a good hash function is designed to make its output indistinguishable from random. There is no header, no checksum, and no version marker in a raw digest.
NTLM is the case that catches people most often. It is MD4 applied to the UTF-16 encoding of a password, so it is 32 hexadecimal characters and looks exactly like MD5. If a 32-character hash came from a Windows domain controller or a SAM dump, it is almost certainly NTLM. If it came from a decade-old PHP application, MD5 is the better guess. The string cannot tell you; the source can.
The same applies to the double-hash constructions still common in legacy code. MD5 applied twice, MD5 of a password concatenated with a salt, and plain MD5 are all 32 hexadecimal characters. Identifying which requires the application's source code or its documentation. This is exactly why format identification is a starting point for a migration plan rather than a conclusion.
What the Format Tells You About Password Storage Quality
If the hash you are examining protects a password, its format is a direct verdict on how well that password was stored. A bare MD5 or SHA-1 digest with no salt and no work factor is the worst case: those functions are fast by design, so commodity hardware tests them in the billions per second, and an unsalted digest means identical passwords produce identical hashes across every account. A general-purpose SHA-256 is no better for this purpose, despite being cryptographically sound for its actual job of integrity checking.
A modular crypt string is a much better sign, because those formats encode a deliberate cost. The $2b$12$ of a bcrypt hash means twelve rounds of key expansion, which is a specific, tunable amount of work per guess. Argon2 goes further by making the computation memory-hard, which blunts the advantage of GPUs. The presence of a per-hash salt inside the string is equally important: it forces an attacker to attack each account separately rather than precomputing one table for all of them. If you are quantifying that difference, the password entropy calculator converts a password into bits and lets you choose the attacker rate that corresponds to the storage method, and the password combination calculator sizes the keyspace a policy actually produces.
Formats That Are Not Password Hashes at All
Plenty of hash-shaped strings have nothing to do with passwords, and misreading one wastes time. An 8-character hexadecimal value is usually a CRC-32 checksum, which is an error-detection code with no cryptographic properties whatsoever — the CRC32 hash generator produces exactly those. A 40-character hexadecimal string in a software repository is far more likely to be a Git object identifier than a password. A 64-character hexadecimal string in a blockchain context is a transaction or block identifier. A 32-character hexadecimal string in a URL is often just a random token or an identifier, and the UUID generator produces the dashed 36-character variant of that idea.
Context resolves all of these instantly and the string resolves none of them. If you are dealing with base64 rather than hexadecimal, the Base64 encoder and decoder will show you whether the value decodes to a sensible byte count, which is often the quickest way to confirm the encoding before worrying about the algorithm.
Arb Digital builds and rebuilds websites with modern password hashing, proper salting, and a migration path off legacy digests that does not lock anyone out.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Stripping the prefix before identifying. The
$2b$12$header is the most informative part of a bcrypt hash. Without it you are guessing from a shapeless blob. - Assuming 32 hex characters means MD5. NTLM, MD4 and RIPEMD-128 all produce the same shape. The source of the value decides, not the value.
- Pasting production hashes into an online service that transmits them. Hashes are credential material. Use something that runs locally, and verify that it does.
- Believing any tool that offers to decode a hash. Hashing is one-way. Such services are looking values up in a breach database or guessing inputs, which is a different operation entirely.
- Treating a matched format as proof. The application may apply a salt, a pepper, or multiple rounds that the digest itself cannot reveal.
Related Free Tools From Arb Digital
To produce digests during development, use the hash generator, and for checksums specifically the CRC32 hash generator. The Base64 encoder and decoder helps confirm an encoding, and the UUID generator covers unique identifiers. On the password side, the password entropy calculator scores an existing password, the password combination calculator sizes a policy's keyspace, and the password generator creates strong values. Everything else is in the free online tools hub.
Frequently Asked Questions
No. The identification runs entirely in your browser using local JavaScript. This page makes no network request of any kind, stores nothing and logs nothing, so the string you paste is never transmitted or seen by us or anybody else.
No, and it does not attempt to. Cryptographic hashing is one-way, so a digest cannot be reversed. This page reads only the length, character set and prefix to report which formats produce that shape.
You cannot tell from the string, because both are 32 hexadecimal characters. NTLM is MD4 applied to the UTF-16 form of a password, so the deciding evidence is the source: a Windows domain or SAM dump points to NTLM, an old web application to MD5.
It is bcrypt in modular crypt format. The digits after the prefix are the cost factor, which sets how much work each guess requires, and the salt is embedded in the same string. It is a strong indicator that passwords were stored deliberately rather than casually.
Because algorithms with the same digest size produce statistically identical output. A raw hash carries no version marker or header, so length and character set frequently narrow the field to a group rather than a single answer.
Not on its own. It is a fast general-purpose hash, which is exactly the wrong property for password storage. Purpose-built functions such as bcrypt, scrypt and Argon2 add a tunable work factor and a per-hash salt.
Almost always a CRC-32 checksum, which detects accidental corruption and has no cryptographic strength at all. Adler-32 produces the same length and is used in some compression formats.
Because base64 encodes three bytes as four characters rather than one byte as two. A 160-bit digest becomes 28 base64 characters and a 256-bit digest becomes 44, so the tool interprets non-hexadecimal alphabets accordingly.
This tool classifies hash formats for informational purposes only. It performs no cracking, lookup or recovery of any kind, and a format match is a hypothesis to confirm against the system that produced the value, not a security assessment.
