NTLM Hash Generator

What is an NTLM hash?

What most people call the “NTLM hash” is properly the NT hash: the value Windows derives from a user’s password and stores instead of the password itself. It is defined very simply. The password is encoded as UTF-16 little-endian (two bytes per character for most text) and then hashed with MD4, producing 128 bits, usually shown as 32 uppercase hex characters. There is no salt and no iteration count.

These values appear in Microsoft documentation and security training, and the tool reproduces them. The empty-password hash in particular is worth recognizing, because seeing it in an audit means an account has no password.

How to use this tool

1. Type a test password. The NT hash appears immediately, together with the number of UTF-16LE bytes that were hashed.
2. Choose uppercase hex (the usual Windows style) or lowercase.
3. Paste a value into the compare box to check that your own script, lab environment or migration tool produces the same result.

Everything runs locally in your browser. Even so, as a general habit, never type a real, in-use password into any website. For other algorithms, including MD4 on arbitrary text and files, use the full hash generator.

Where Windows uses the NT hash

Local accounts keep their NT hashes in the Security Account Manager (SAM) database, and Active Directory domain controllers keep them for every domain account. The NTLM family of authentication protocols (NTLMv1 and NTLMv2) uses the NT hash as the secret key in a challenge–response exchange, so a client proves it knows the hash rather than sending the password. Modern domains prefer Kerberos, and NTLM remains mainly as a fallback for older systems, workgroup machines and applications that were never updated. Microsoft has announced that NTLM is deprecated and is removing the oldest version, NTLMv1, from new Windows releases.

An even older format, the LAN Manager (LM) hash, uppercased passwords and split them into 7-character halves. It has been disabled by default since Windows Vista and Windows Server 2008. If you still see LM hashes stored anywhere, that is a finding to fix.

Why the NT hash is weak

• No salt. The same password always produces the same NT hash, on every machine and in every organization. Identical hashes reveal shared passwords, and precomputed tables work against every account at once.
• Very fast. MD4 was built for speed. Modern password storage deliberately uses slow, memory-hard functions such as Argon2id or bcrypt; the NT hash has none of that protection, so weak passwords fall quickly if the hashes leak.
• MD4 itself is broken. MD4 collisions are trivial to create. That matters less for passwords than speed and the missing salt, but it means the format has no security margin left.
• The hash works like the password. Because NTLM authentication proves knowledge of the hash, not the password, a stolen NT hash can be enough to sign in to other systems that accept NTLM. This class of attack is known as pass-the-hash, and it is why NT hashes must be protected as carefully as plain-text passwords.

How to protect Windows accounts

If you administer Windows systems, these widely recommended measures reduce the risk from NT hashes:

• Reduce and then disable NTLM. Audit where NTLM is still used, move those systems to Kerberos, and use the “Restrict NTLM” group policies to block it step by step.
• Turn on Credential Guard and other built-in credential protections so secrets are harder to extract from memory.
• Use unique local administrator passwords, for example with Windows LAPS, so one machine’s hash does not unlock every other machine.
• Separate administrative accounts and only use privileged accounts on hardened admin workstations.
• Require long passphrases and MFA, and check passwords against lists of known breached passwords.
• Enable SMB signing and extended protection to block relay attacks against NTLM authentication.

Don’t use NT hashes in new designs

If you are building an application, never store passwords as NT hashes, MD5 or SHA-256. Use a slow, salted password hash such as Argon2id or bcrypt; you can experiment with bcrypt in the bcrypt generator. The only reason to compute an NT hash today is compatibility with existing Windows systems: testing, migrations, lab work and learning how the format works.

Common questions about the encoding

The NT hash is computed over UTF-16LE bytes, not UTF-8, so the same password gives a different hash here than in an ordinary MD4 tool that hashes UTF-8. Passwords are case-sensitive, and every character counts, including trailing spaces. Characters outside the Basic Multilingual Plane, such as many emoji, take four bytes in UTF-16 (a surrogate pair), and the tool encodes them the same way Windows does.

Frequently asked questions