NTLM Hash Generator

Need to turn a password into its Windows fingerprint without opening a terminal? This NTLM hash generator takes any text you type and returns a 32-character hexadecimal digest: the MD4 hash of your password encoded as UTF-16LE. It is the same NT hash a Windows domain stores for an account, so you can compare values, build test fixtures and check your own scripts against a known-good result.

What an NTLM hash is and why Windows uses it

NTLM stands for NT LAN Manager, a Microsoft authentication protocol that Windows servers and clients still speak for compatibility with older systems. When people talk about an NTLM password hash they usually mean the NT hash: a one-way function result stored instead of the cleartext password. The server never needs the original text, only a value it can compare against. A password hash like this works as an authentication hash: during the NTLM challenge response exchange the client proves it holds the right value without ever sending the password across the network.

The algorithm is short, and MD4 is a fast hash function designed in 1990 that was never meant to resist modern cracking hardware. Windows takes your password, encodes it as UTF-16LE (two bytes per character, low byte first), and runs MD4 over those bytes. The output is 128 bits, written as 32 hexadecimal characters. In formula form:

$$\text{NT hash} = \text{MD4}\big(\text{UTF-16LE}(\text{password})\big)$$

Because the result is a pure function of the input, identical passwords always produce identical hashes. That is the property developers rely on in unit tests, and the property attackers rely on when they build precomputed tables.

NTLM, LM hash and NetNTLM are different things

Three names get mixed up constantly. The LM hash is a much older DES-based format that uppercases the password first and is very weak. The NTLM hash is the MD4 value this tool produces. NetNTLM (v1 and v2) is not a stored hash at all: it is a challenge/response value built during a network login, with several fields, so you cannot paste it into a hash calculator and expect a match. The same goes for values copied from a packet capture: a challenge response blob and an NT hash only look related because both are hex.

How to generate an NTLM hash with this online tool

Think of it as a simple hash calculator for one job: you give it text, it gives you the matching NT value. Programmers and administrators both use it, because a hash calculator removes the guesswork about encodings and byte order. The free postgres md5 password hash generator gives you a copy-ready result instantly, with no account required.

Using the online NTLM hash generator takes three steps, and nothing about the process needs an account.

• Type or paste the password, or any other string, into the input box.
• Press the button to calculate NTLM hash output, or leave the box empty to see the known value for an empty password.
• Copy the 32 hex output, which is uppercase or lowercase depending on what your target system expects.

Hex case does not change the value, only how it is written. Many tools print NT hashes in lowercase, while Windows tooling often shows uppercase. If a comparison fails, normalize the case before assuming the hashes differ.

Worked example: one password, five different results

Take the 17-character password Harbor-Lantern47!. Encoded as UTF-16LE it becomes 34 bytes, starting 48 00 61 00 72 00, and MD4 over those bytes gives 8f8df6ace8c206849232adb50a02d97f. Small changes to the input show how sensitive the digest is:

The last row is the classic mistake: the right password hashed with the wrong encoding. If your own script disagrees with the tool for a plain ASCII password, check this first. Hashing the same text with MD5 instead of MD4 gives a different 32-hex string again, 434820d5c95b5910365e11f22de0572b for this password, which is why the two are so easy to confuse.

Why the UTF-16LE encoding matters for non-ASCII characters

For ASCII text, UTF-16LE looks like the original bytes with a zero byte after each one, so an error often goes unnoticed. The difference becomes visible with accents and other non-ASCII characters. The letter ü is the single byte fc in UTF-16LE (as fc 00) but two bytes in UTF-8, so the digests diverge completely.

Reproducing the calculation in code

You can reproduce any result from this page in a few lines. In PHP, iconv('UTF-8', 'UTF-16LE', $password) followed by hash('md4', ...) does it. In Python, encode the string with 'utf-16le' and pass the bytes to an MD4 implementation (some OpenSSL builds disable MD4, so you may need a small pure-Python version). In PowerShell, the DSInternals module offers a cmdlet that takes a SecureString and returns the NT hash, which keeps the plaintext out of your shell history.

Checking a failing test fixture with the NTLM hash calculator

A failing test is open on a Friday afternoon. The library under test sends NTLM credentials to a lab Windows Server 2022 domain, and the fixture for the service account svc-müller says the expected NT hash is 989c26f1249a9976eff15e143d330845. The login is rejected anyway, so the question is whether the fixture or the server is wrong.

The account password is Müller-2026, 11 characters. Pasting it into the tool and pressing the button returns 43b44c14031a0894a19fd7f709e1b4cd. That is not the fixture's value, which means the fixture, not the server, is off.

The next check is where the old value came from. Encoding the same password as UTF-8 and running MD4 gives 989c26f1249a9976eff15e143d330845, an exact match for the fixture. In UTF-8 the ü is the two bytes c3 bc; in UTF-16LE it is fc 00, and that single byte is enough to change all 32 hex characters.

1. Microsoft's NTLM specification, MS-NLMP, defines the NT one-way function as MD4 over the Unicode (UTF-16LE) password, so 43b44c14… is the value the domain controller holds.
2. The fixture helper is changed to encode with 'utf-16le' instead of 'utf-8'.
3. The test is rerun with the new fixture, and the login against the lab domain succeeds.

One input value and one comparison settled a bug that would otherwise have meant packet captures. Every other fixture with a non-ASCII password gets the same re-check before the suite goes back into the pipeline.

Free NTLM hash calculator uses for developers and testers

A web developer or programmer rarely needs to crack anything; they need correct fixtures. Typical jobs include:

• Writing unit tests for an application that talks to Windows servers, where the plain-text password is the input and the NT hash is the expected output.
• Seeding test credentials into a lab domain, an SQL Server instance or an IIS site before cross-browser testing.
• Deciding whether a mismatch comes from your application code or from a different password hash format altogether.
• Checking that a library, an SMB client or a Kerberos fallback path computes the same hash as a trusted reference.
• Generating random sample hashes, since any NT hash is just 32 hex characters, or hashing a random string to fill a test database with realistic-looking records.

Developers building applications that authenticate against Active Directory often keep a small table of known passwords and hashes next to their tests, so a regression in encoding shows up immediately. If you only need to generate NTLM hash values for a few fixtures, this page is quicker than wiring up a library; as an NTLM password hasher it is a convenience, not a replacement for your build pipeline, and any random value it produces is only as strong as the text you typed in.

Running a batch of test passwords through the tool one at a time is fine for a handful of values. For hundreds, script the calculation locally so the data never leaves your machine.

NTLM hash generator and lookup: what decrypting really means

Searches for "decrypt NTLM" are common, but a hash is not encrypted, so there is nothing to decrypt. A lookup service compares your digest against a database of known plaintexts and their hashes. If the plaintext is in that corpus, you get a match; if the password is long, random or uses rarely indexed characters, you do not. A dictionary of common passwords hashed in advance is exactly why unsalted NTLM is considered weak.

This page focuses on the generation direction. When you need to go the other way for an audit, use the lookup only on hashes from systems you are authorized to assess.

Security guidance for the NT hash and legacy authentication

The NT hash has no salt, so two users with the same password share the same value, and anyone who obtains the digest can often use it directly in pass-the-hash attacks without ever learning the password. That makes it a poor choice for new password storage. Use a slow, salted algorithm such as bcrypt, scrypt or Argon2 for anything you build, and treat NTLM as legacy Windows compatibility, not a design choice. Also keep in mind that the same 32-hex shape is shared by MD5, so context is often the only way to tell them apart, while longer digests such as SHA1 or SHA-2 are easy to spot by length.

Finally, hash only test strings and credentials you own. Typing a real production password into any website, including this one, is a habit worth avoiding.

Frequently Asked Questions

What is the NTLM hash used for?

It's the format Windows has used since NT to store password verifiers locally (in the SAM database) and in Active Directory (NTDS.dit) -- and it's still used today in the NTLM authentication protocol for network logons, even on modern Windows systems, for backward compatibility.

Why does NTLM use MD4, and is that a problem?

MD4 was chosen when NTLM was designed in the early 1990s, well before MD4's cryptographic weaknesses (practical collision attacks) were discovered. Because NTLM has no salt and MD4 is extremely fast, precomputed rainbow tables and GPU brute-force attacks against NTLM hashes are very effective -- this is a well-known, long-standing weakness that's exactly why NTLM is considered legacy and Kerberos is preferred wherever possible.

Why UTF-16LE and not UTF-8?

Windows has used UTF-16LE as its native internal string encoding since NT, so NTLM hashes the password exactly as Windows represents it internally -- 2 bytes per character, little-endian byte order -- rather than converting to UTF-8 first.

Is this the same as a Windows password hash dump?

It's the same NT hash value that tools like Mimikatz or a SAM database dump would show for that password -- but generating one here doesn't interact with any real Windows system. This tool exists for security research, penetration testing labs, and understanding how NTLM authentication works, not for attacking systems you don't have authorization to test.

Is my password sent anywhere?

No. The hash is computed entirely in your browser using a hand-rolled MD4 implementation -- nothing is transmitted to a server or stored.