Can you tell me exactly which hash this is?

For a bare digest, no. All the string gives you is length and alphabet, and several algorithms produce the same shape. A 32-character hex value can be MD5, NTLM, MD4, RIPEMD-128 or LM. Source context and comparison with a known input can narrow the candidates; a value from a Windows store or download page is useful context but does not prove the algorithm by itself. Prefix recognition also describes the record format without proving that the checksum is valid.

How do I tell MD5 from NTLM, then?

By context, and by testing rather than by looking. Both are 128 bits and both are usually written as 32 hex characters, so the two are the same shape. NTLM is MD4 of the password encoded in UTF-16LE with no salt, and it shows up in Windows account databases, domain controller dumps and pass-the-hash traffic. MD5 shows up almost everywhere else: file checksums, old application password columns, ETag values, content addresses. If you have the input that produced the digest, hash it both ways and compare; that is the one check that settles it, and it is a job for a hashing tool rather than this page.

What do $2b$, $6$ and $argon2id$ at the start mean?

They are the modular crypt format, and they are the one case where a string does name its own scheme. A stored password record was designed to be self describing so a server can check a password years after the algorithm was changed, so it carries the scheme, then the work factor, then the salt, then the checksum, separated by dollar signs. $2a$, $2b$, $2y$ and $2x$ are bcrypt, $1$ is md5crypt, $apr1$ is the Apache variant, $5$ and $6$ are sha256crypt and sha512crypt, $y$ is yescrypt, $P$ and $H$ are the phpass records WordPress and phpBB use, and $argon2id$ is Argon2id, whose record carries its memory, time and parallelism costs. This page reads all of those, plus the LDAP schemes in braces such as {SSHA} and Django's pbkdf2_sha256$ records. It marks each one as a record rather than a digest and gives no byte count, because the characters after the prefix are a work factor, a salt and a checksum rather than one number to count. MySQL's asterisk is the exception it treats differently: the 40 hex characters behind the asterisk really are a plain digest, so those 20 bytes are counted.

Is my hash uploaded, cracked or looked up anywhere?

No. The page makes no network request of its own, so the digest is read in your tab and goes nowhere, and there is no account or sign-up in front of it. There is also no cracking and no rainbow table: the tool takes a string and describes how it is written, which is all it can do without the input that produced it. The digest is not even kept on your device. What this browser remembers is the example you last opened and whether the candidate filter is on, and the Start over button above the tool forgets both of those.

I pasted a whole line from md5sum and it still worked. Why?

Because a checksum listing prints the digest and then the file name, and a password list often prints the hash and the salt joined by a colon, so both are read: the tool takes the field that has the shape of a digest and tells you, in a note under the result, exactly which text it left out. Nothing is dropped quietly: the note quotes the text it ignored, so you can see which field was read, and the copied report prints that field on its own line. Surrounding spaces and a trailing newline are trimmed the same way.

Why does it say a 32 byte base64 value might be an API key?

Because it might. base64 carries three bytes in every four characters, so a 44 character base64 string with one equals sign at the end is 32 bytes, and 32 bytes is SHA-256, SHA3-256 or BLAKE2s-256, and it is equally a random API key, a session token or a raw encryption key. Length cannot tell a digest from any other 32 bytes. The page says so rather than letting a list of hash names imply the string is a hash at all, and it recognises two common impostors outright: a UUID in its five dash separated groups, and a JSON Web Token in its three dot separated base64url parts.

What about a checksum like CRC-32?

It is listed, and it is labelled. Eight hex characters is CRC-32, Adler-32 or a 32 bit non-cryptographic hash, and none of those is a cryptographic hash: they exist to spot accidental corruption, not tampering. The same goes for CRC-64 and MySQL's pre-4.1 OLD_PASSWORD at 16 hex characters. If you only want cryptographic schemes, the filter above the examples hides the rest, and it says how many it hid rather than shortening the list without telling you.

It says no format is written this way. What went wrong?

Usually a character was lost or gained on the way into the box. An odd number of hex characters cannot be a whole number of bytes, so the page says that rather than rounding to half a byte, and a hex length no scheme uses, such as 34 characters, gets the byte count and an empty list. Check for a truncated copy, a prefix that was cut off, or leading text that is not part of the digest. The tool reads up to 4,096 characters in one go and refuses a longer paste with both numbers quoted, rather than reading part of it.

Does this give a Hashcat mode or install hash-identifier on Kali?

No. It lists possible formats from supplied text in your browser. It does not assign Hashcat numeric modes, run cracking tools, install packages, provide a command-line program or assess the strength of an unknown hash from its appearance. Use UUID Generator or JWT Decoder when the shape is an identifier or token, and Bcrypt Generator to check a known password against a supported bcrypt record.

Hash Identifier

Paste a digest and this page lists every format that is written the way yours is, with the reason each one fits. What is different here is that it never picks a winner: a bare digest has no header, so 32 hex characters is MD5 exactly as much as it is NTLM, MD4, RIPEMD-128 or LM, and a page that answers with one name is guessing on your behalf. You get the whole list, the byte count behind it, and a note saying whether the match came from the shape or from a prefix the string wrote about itself. Stored password records are the case that does name itself, and $2b$, $6$, $argon2id$, {SSHA} and pbkdf2_sha256$ are read by that prefix and marked as records rather than raw digests. Nothing is cracked, reversed or looked up, nothing is uploaded, and the digest you paste is never written to your device.

digest32 hex

candidates5 possible

MD5128 bit128 bit digest, written as 32 hex characters. The most common thing written this way, and broken for anything security depends on.
NTLM128 bit128 bit digest, written as 32 hex characters. How Windows stores a password: MD4 of the password in UTF-16LE, unsalted.
MD4128 bit128 bit digest, written as 32 hex characters. The design MD5 and NTLM came from.
RIPEMD-128128 bit128 bit digest, written as 32 hex characters.
LM128 bit128 bit digest, written as 32 hex characters. The older Windows LAN Manager password hash, which is also written as 32 hex.

Length

32 hex

Bytes

Candidates

Prefix

none

32 hex characters, 16 bytes. 5 known formats are written this way, and nothing in the string itself says which. MD5, NTLM, MD4, RIPEMD-128, LM.

Show

possible, from length and alphabet

Hex writes two hex characters per byte, so the byte count is half the character count.

32 hex charactersno prefix
MD5, NTLM, MD4 and 2 more
$2b$ prefix60 characters
bcrypt
64 hex charactersno prefix
SHA-256, SHA3-256, BLAKE2s-256 and 4 more

How the answer is reached. A digest is a fixed number of bytes with no header in front of it, so the evidence is the length, the alphabet and any prefix. Hex is two characters per byte, base64 carries three bytes in every four characters, and the byte count picks the row: 16 bytes is MD5 and also NTLM, MD4, RIPEMD-128 and LM, and nothing in the string separates them. A stored password record is the one case that names itself, because $2b$, $6$, $argon2id$ and the rest were designed to say what made them, and the cost and salt that follow are text rather than digest. What no shape can show is whether the input was salted first, whether an encoding step came after, or whether the string is a hash at all: 32 bytes of base64 is just as likely to be an API key.

Up to 4,096 characters in one reading, done here in your browser with no upload and no account. The digest is never written to this device: what is kept is the example you last opened and the candidate filter, and the Start over button above the tool forgets those too.

Accuracy. A format guess from length, alphabet and any known prefix, and nothing more: several schemes share a shape, so more than one candidate is normal and the page lists them all with its reason. It does not crack, reverse or look up anything, and nothing you paste leaves the browser.

Hash length and prefix reference

Lengths produce candidate sets, not proof of an algorithm. Prefixes describe stored records; their structure alone does not verify the password or digest.

Observed text	Possible formats
8 hex characters	CRC-32, Adler-32 and other 32-bit checksums
16 hex characters	CRC-64 and legacy MySQL OLD_PASSWORD
32 hex characters	MD5, MD4, NTLM, RIPEMD-128, LM
40 hex characters	SHA-1, RIPEMD-160
64 hex characters	SHA-256, SHA3-256, BLAKE2s-256
128 hex characters	SHA-512, SHA3-512, BLAKE2b-512
$2a$, $2b$, $2y$, $2x$	Bcrypt record; this identifier does not verify it
$1$, $apr1$, $5$, $6$	Unix crypt records
$argon2id$, {SSHA}, pbkdf2_sha256$	Argon2, LDAP or Django record by prefix

Common questions

Can you tell me exactly which hash this is?: For a bare digest, no. All the string gives you is length and alphabet, and several algorithms produce the same shape. A 32-character hex value can be MD5, NTLM, MD4, RIPEMD-128 or LM. Source context and comparison with a known input can narrow the candidates; a value from a Windows store or download page is useful context but does not prove the algorithm by itself. Prefix recognition also describes the record format without proving that the checksum is valid.
How do I tell MD5 from NTLM, then?: By context, and by testing rather than by looking. Both are 128 bits and both are usually written as 32 hex characters, so the two are the same shape. NTLM is MD4 of the password encoded in UTF-16LE with no salt, and it shows up in Windows account databases, domain controller dumps and pass-the-hash traffic. MD5 shows up almost everywhere else: file checksums, old application password columns, ETag values, content addresses. If you have the input that produced the digest, hash it both ways and compare; that is the one check that settles it, and it is a job for a hashing tool rather than this page.
What do $2b$, $6$ and $argon2id$ at the start mean?: They are the modular crypt format, and they are the one case where a string does name its own scheme. A stored password record was designed to be self describing so a server can check a password years after the algorithm was changed, so it carries the scheme, then the work factor, then the salt, then the checksum, separated by dollar signs. $2a$, $2b$, $2y$ and $2x$ are bcrypt, $1$ is md5crypt, $apr1$ is the Apache variant, $5$ and $6$ are sha256crypt and sha512crypt, $y$ is yescrypt, $P$ and $H$ are the phpass records WordPress and phpBB use, and $argon2id$ is Argon2id, whose record carries its memory, time and parallelism costs. This page reads all of those, plus the LDAP schemes in braces such as {SSHA} and Django's pbkdf2_sha256$ records. It marks each one as a record rather than a digest and gives no byte count, because the characters after the prefix are a work factor, a salt and a checksum rather than one number to count. MySQL's asterisk is the exception it treats differently: the 40 hex characters behind the asterisk really are a plain digest, so those 20 bytes are counted.
Is my hash uploaded, cracked or looked up anywhere?: No. The page makes no network request of its own, so the digest is read in your tab and goes nowhere, and there is no account or sign-up in front of it. There is also no cracking and no rainbow table: the tool takes a string and describes how it is written, which is all it can do without the input that produced it. The digest is not even kept on your device. What this browser remembers is the example you last opened and whether the candidate filter is on, and the Start over button above the tool forgets both of those.
I pasted a whole line from md5sum and it still worked. Why?: Because a checksum listing prints the digest and then the file name, and a password list often prints the hash and the salt joined by a colon, so both are read: the tool takes the field that has the shape of a digest and tells you, in a note under the result, exactly which text it left out. Nothing is dropped quietly: the note quotes the text it ignored, so you can see which field was read, and the copied report prints that field on its own line. Surrounding spaces and a trailing newline are trimmed the same way.
Why does it say a 32 byte base64 value might be an API key?: Because it might. base64 carries three bytes in every four characters, so a 44 character base64 string with one equals sign at the end is 32 bytes, and 32 bytes is SHA-256, SHA3-256 or BLAKE2s-256, and it is equally a random API key, a session token or a raw encryption key. Length cannot tell a digest from any other 32 bytes. The page says so rather than letting a list of hash names imply the string is a hash at all, and it recognises two common impostors outright: a UUID in its five dash separated groups, and a JSON Web Token in its three dot separated base64url parts.
What about a checksum like CRC-32?: It is listed, and it is labelled. Eight hex characters is CRC-32, Adler-32 or a 32 bit non-cryptographic hash, and none of those is a cryptographic hash: they exist to spot accidental corruption, not tampering. The same goes for CRC-64 and MySQL's pre-4.1 OLD_PASSWORD at 16 hex characters. If you only want cryptographic schemes, the filter above the examples hides the rest, and it says how many it hid rather than shortening the list without telling you.
It says no format is written this way. What went wrong?: Usually a character was lost or gained on the way into the box. An odd number of hex characters cannot be a whole number of bytes, so the page says that rather than rounding to half a byte, and a hex length no scheme uses, such as 34 characters, gets the byte count and an empty list. Check for a truncated copy, a prefix that was cut off, or leading text that is not part of the digest. The tool reads up to 4,096 characters in one go and refuses a longer paste with both numbers quoted, rather than reading part of it.
Does this give a Hashcat mode or install hash-identifier on Kali?: No. It lists possible formats from supplied text in your browser. It does not assign Hashcat numeric modes, run cracking tools, install packages, provide a command-line program or assess the strength of an unknown hash from its appearance. Use UUID Generator or JWT Decoder when the shape is an identifier or token, and Bcrypt Generator to check a known password against a supported bcrypt record.

A format guess from length, alphabet and any known prefix, and nothing more: several schemes share a shape, so more than one candidate is normal and the page lists them all with its reason. It does not crack, reverse or look up anything, and nothing you paste leaves the browser.