CodeKitHubWhat Is This Tool?
NTLM (NT LAN Manager) is Microsoft's legacy challenge-response authentication protocol, still used today for local Windows account logons and as a fallback in many Active Directory environments. Its password verifier — commonly called "the NTLM hash" — is defined in Microsoft's own MS-NLMP protocol specification as `MD4(UTF-16-LE(password))`: the password is first encoded as UTF-16 little-endian (so every character becomes 2 bytes, unlike UTF-8), and that byte sequence is then hashed once with the MD4 algorithm from RFC 1320.
The UTF-16LE step is the detail most people get wrong when reimplementing NTLM: hashing the UTF-8 bytes of a string instead of its UTF-16LE bytes produces a completely different, incorrect digest, even though the visible text looks identical. This tool encodes correctly, so its output matches what Windows itself stores and what tools like hashcat (mode 1000) and Mimikatz expect.
Because NTLM predates modern password-hashing design, it has none of the protections that were later built specifically to slow down cracking: no per-user salt, no configurable work factor, and no deliberate iteration. It is a single MD4 pass, which makes it extremely fast to compute — a property that is convenient for legacy compatibility but disastrous for resisting brute-force and dictionary attacks.
Why Use It?
- You just extracted a batch of hashes from a client's NTDS.dit during an authorized pentest and want to sanity-check that your own parsing script produced the correct hash format before feeding the full dump into hashcat.
- You're building a custom credential-auditing tool and just wrote your own MD4(UTF-16LE) implementation from the MS-NLMP spec — paste a known test vector like "password" here to confirm your code's output matches the correct 8846F7EAEE8FB117AD06BDD830B7586C before trusting it on real data.
- You're working through a CTF challenge or a home lab exercise on Windows authentication and need to quickly compute what a given password's NTLM hash should look like, without spinning up a Windows VM just to check one value.
- You're teaching a security course on legacy authentication weaknesses and want to show students, live, why NTLM's lack of salting means the same password always produces the identical hash — no matter which account or domain it belongs to.
- 100% local: your input never leaves the browser, so it's safe to use even for sensitive credential material in an authorized assessment.
How to Use
- Type the password or string you want to hash into the input box.
- Click "Generate NTLM Hash".
- Read the 32-character hexadecimal NTLM hash (uppercase output is on by default, matching how Windows and most cracking tools display it — untick the box for lowercase).
- Click "Copy" to copy the hash to your clipboard.
Example
Input
passwordOutput
8846F7EAEE8FB117AD06BDD830B7586CThis is a well-known, independently verifiable test vector: the NTLM hash of the literal string "password" is always 8846F7EAEE8FB117AD06BDD830B7586C. You can check this tool's output against any other correct NTLM implementation.
NTLM vs. modern password hashing
The table below highlights why NTLM is considered obsolete for protecting new systems, even though it remains embedded in legacy Windows and Active Directory infrastructure.
| Property | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| Underlying primitive | Single MD4 pass | Purpose-built slow hash with tunable cost |
| Salting | None — identical passwords always hash identically | Unique random salt per password |
| Iteration / stretching | None | Configurable work factor, increasable over time |
| Brute-force resistance | Very weak — billions of guesses/sec on modern GPUs | Deliberately expensive per guess |
| Where it's still found | Legacy Windows auth, Active Directory fallback | New applications, current best practice |
Related tools
If you need a general-purpose cryptographic hash rather than the NTLM-specific MD4(UTF-16LE) construction, these tools may be a better fit.
→ Multi-Algorithm Hash Generator · MD5 Generator · Password Generator
Common NTLM verification workflows
This tool is most useful as a quick sanity-check step inside a larger authorized workflow — confirming a value before you trust it in a bigger pipeline, rather than replacing that pipeline entirely.
| Scenario | What you're checking | Why it matters |
|---|---|---|
| Custom script validation | Your own MS-NLMP implementation against a known test vector | Catches the UTF-8 vs. UTF-16LE bug before it silently corrupts a whole dataset |
| Dumped hash spot-check | One extracted SAM/NTDS.dit entry against an expected plaintext | Confirms your extraction tooling parsed the format correctly |
| hashcat/Mimikatz format check | Output structure matches mode 1000 expectations | Prevents wasted cracking runs against a malformed hash list |
| Training and CTF exercises | A hand-computed hash against the tool's output | Builds intuition for how MS-NLMP actually works, step by step |
Frequently Asked Questions
What exactly is an NTLM hash?
It's the password verifier Windows computes and stores for NT LAN Manager authentication, defined in Microsoft's MS-NLMP specification as MD4(UTF-16LE(password)) — a single MD4 pass over the password's UTF-16 little-endian byte encoding. It's always 128 bits, shown as 32 hex characters.
Why UTF-16LE specifically, and not UTF-8 or ASCII?
Windows has stored text internally as UTF-16LE since NT was designed, so passwords are encoded that way before hashing too. Every character becomes 2 bytes (little-endian byte order), including plain ASCII characters like 'a', which become 0x61 0x00 instead of just 0x61. Hashing the UTF-8 bytes of the same string produces a totally different, wrong result — this is the single most common bug in from-scratch NTLM implementations.
Is NTLM secure to use today?
No, and Microsoft itself recommends moving away from it in favor of Kerberos where possible. NTLM has no salt, so identical passwords always produce identical hashes across every user and every system, enabling precomputed rainbow-table lookups. It also has no iteration or work-factor — a single unsalted MD4 pass — so modern GPUs can attempt billions of guesses per second against a captured hash. It survives mainly for legacy compatibility with older Windows systems and applications.
How is NTLM different from modern password hashing like bcrypt, scrypt, or Argon2?
Modern password hashers are deliberately slow and salted: bcrypt, scrypt and Argon2 each add a unique random salt per password and a tunable cost factor that can be increased over time as hardware gets faster, specifically to make brute-forcing expensive even at scale. NTLM does neither — it was designed in an era before offline brute-forcing was a practical threat model, and it shows. This is exactly why NTLM should never be used to protect anything designed today; this tool's real use cases are compatibility with existing Windows infrastructure and authorized security testing, not building new systems.
What are legitimate uses for an NTLM hash generator?
Verifying hashes pulled from a SAM database or NTDS.dit during an authorized penetration test or credential audit; checking that your own tooling or scripts implement MS-NLMP correctly; generating test hashes for hashcat (mode 1000) or Mimikatz-format compatibility checks in a lab you control; and working through CTF or training exercises that explicitly involve NTLM. Using this tool to attack accounts or systems you don't own or have written authorization to test is not a legitimate use.
Is my password or input sent to a server?
No. The MD4 computation runs entirely in JavaScript in your browser — there is no native browser API for MD4, so it's implemented directly in this page's client-side code, and nothing you type is transmitted anywhere.
Does this tool handle the LM hash too, or only NTLM?
Only NTLM. The older LM hash uses a completely different, weaker scheme (splitting the password into two 7-character halves and hashing each with DES), and Microsoft has disabled LM hash storage by default since Windows Vista. If you need to work with legacy LM hashes specifically, you'll need a separate tool built for that algorithm.
Why does the same input always produce the exact same hash, with no randomness?
That's expected and matches real NTLM behavior exactly — NTLM has no salt, so MD4(UTF-16LE(input)) is a pure deterministic function. The identical input always yields the identical output, which is precisely the weakness that makes NTLM vulnerable to precomputed rainbow-table attacks.
Can I use this to hash something other than a password, like a username or a challenge value?
Technically yes — the tool just computes MD4(UTF-16LE(input)) on whatever text you enter, so it works for any string. But if you're working through the fuller NTLMv2 challenge-response handshake (which involves the NTLM hash plus a server challenge, client nonce, and HMAC-MD5), you'll need additional steps beyond this single-hash calculator.
How can I verify this tool's output is actually correct?
Use the built-in example: the NTLM hash of the literal string "password" is a well-known, independently published test vector — 8846F7EAEE8FB117AD06BDD830B7586C. Type it in and confirm you get that exact result, then cross-check against another trusted implementation like hashcat's own test vectors if you want further confidence.
Does case sensitivity or trailing whitespace affect the output?
Yes, exactly as it does in real NTLM — the algorithm hashes the exact bytes you provide, so "Password" and "password" produce completely different hashes, and an accidental trailing space changes the result too. This is worth double-checking when verifying a hash extracted from another source.