Hash Generator (MD5, SHA-256…)

A hash generator turns any text or file into a short, fixed-length fingerprint. Our free tool calculates MD5, SHA-1, SHA-256, SHA-384 and SHA-512 at the same time, shows each one in hex or Base64, and can produce HMAC signatures with a secret key for webhooks and APIs. Paste the checksum from a download page into the compare box and it tells you straight away whether your file matches. Everything is worked out in your browser with the Web Crypto API and a built-in MD5 routine, so your text, files and keys never leave your device.

How to use the Hash generator

1. 1 Choose text or filePick Text to hash a string such as a password test value, an API payload or a line from a config file, or pick File to hash a download, an export or a backup.
2. 2 Add your inputType or paste the text, or choose the file. Text is encoded as UTF-8, and files are read on your device, up to 1 GB.
3. 3 Turn on HMAC if you need a signatureTick HMAC and enter the shared secret when you are checking or building a webhook or API signature. Leave it off for a plain checksum.
4. 4 Pick hex or Base64Hex is what most download pages and command-line tools show. Base64 is common in HTTP headers, Subresource Integrity and some webhook signatures.
5. 5 Compare with the expected valuePaste the published checksum into the compare box. A green match tells you which algorithm it is; a red no match means the file or text is not the same.

What a hash is and why it is useful

A cryptographic hash function takes input of any size, from a single letter to a multi-gigabyte disk image, and produces an output of a fixed size. SHA-256 always gives 256 bits, shown as 64 hexadecimal characters, whether you feed it the word hello or an entire film. The same input always gives the same hash, but changing even one character, one space or one byte produces a completely different result. That property is what makes hashes so useful for spotting changes.

Good hash functions are also one-way: you cannot work backwards from the hash to the original input, other than by guessing inputs and hashing them until one matches. And for a secure algorithm it should be practically impossible to find two different inputs that produce the same hash, which is called a collision. These three ideas, fixed size, sensitivity to change and one-way design, explain nearly every everyday use of hashing.

You meet hashes all the time without noticing. Git identifies every commit by a hash. Package managers check downloaded libraries against hashes in a lock file. Browsers use hashes in Subresource Integrity attributes to make sure a script from a CDN has not been tampered with. Backup tools use them to work out which files have changed since last night, and many websites use them to build cache-busting file names for stylesheets and scripts.

Checking a download with a checksum

Many software publishers list a SHA-256 checksum next to each download, especially for operating system images, firmware, password managers and developer tools. Checking it confirms that the file on your computer is exactly the file the publisher released, and that it was not corrupted during download or swapped for something else on a mirror.

To check a file here, switch to File, choose the download and paste the published value into the compare box. If you see a match, the file is identical byte for byte. If you see no match, do not run the file. Download it again from the official site, and if it still does not match, contact the publisher. A checksum only helps if you get it from a trustworthy source, ideally the publisher's own HTTPS page, because anyone who can replace the file on a compromised site can often replace the checksum too. Some projects also sign their checksum files with GPG for that reason.

If you prefer the command line, Windows has Get-FileHash in PowerShell and certutil -hashfile, macOS has shasum -a 256, and Linux has sha256sum. They all produce the same values as this tool. Hashing in the browser is simply more convenient when you only need to check one file, and the file is never uploaded, which matters for private documents and large installers alike.

MD5, SHA-1, SHA-256, SHA-384 and SHA-512 compared

All five algorithms are shown together because different systems still ask for different ones. They are not equally strong, though, and it is worth knowing which to trust for what.

• MD5 (128-bit, 32 hex characters): very fast and still common for non-security checksums, ETags and de-duplication. Collisions can be created deliberately on ordinary hardware, so it must not be used to protect against tampering.
• SHA-1 (160-bit, 40 hex characters): stronger than MD5 but practical collisions have been publicly demonstrated. Browsers and certificate authorities stopped accepting it for certificates years ago. Fine for legacy compatibility, not for new security work.
• SHA-256 (256-bit, 64 hex characters): part of the SHA-2 family and the sensible default today for checksums, signatures and integrity checks.
• SHA-384 (384-bit, 96 hex characters): a SHA-2 variant often used in TLS and in Subresource Integrity attributes, where sha384 is a common choice.
• SHA-512 (512-bit, 128 hex characters): the largest SHA-2 output. It can be quicker than SHA-256 on 64-bit processors and is used in some signing and key derivation schemes.

HMAC: hashes with a secret key

A plain hash proves that data has not changed, but anyone can calculate it, so it does not prove who sent the data. HMAC, short for hash-based message authentication code, mixes a secret key into the calculation. Only someone who knows the key can produce the right value, so a matching HMAC shows both that the message is intact and that it came from someone holding the key.

Payment providers, e-commerce platforms, form builders and chat tools commonly sign their webhooks this way. The sender calculates an HMAC, usually HMAC-SHA256, over the raw request body and puts it in a header; your server recalculates it with the shared secret and rejects the request if the two do not match. When an integration fails, this tool is a quick way to see what the signature should be for a given payload and key. Remember that the exact bytes matter: a reformatted JSON body, an extra new line or a different character encoding will give a different HMAC.

Check the provider's documentation for details such as whether a timestamp is prepended to the body, and whether the result is expected in hex or Base64. On your server, compare signatures with a constant-time function such as hash_equals in PHP or hmac.compare_digest in Python rather than an ordinary string comparison.

Why fast hashes are wrong for passwords

It is tempting to store a SHA-256 of each password and call it secure, but general-purpose hashes are designed to be fast, and fast is exactly what an attacker wants. Modern graphics cards can test billions of MD5 or SHA-256 guesses per second, so if a database of fast password hashes leaks, most real-world passwords can be recovered quickly. Adding a single static salt does not fix the speed problem.

Passwords should be stored with a slow, salted password hashing function designed for the job: Argon2id, scrypt or bcrypt. Most frameworks already do this for you, for example Laravel's Hash facade and PHP's password_hash function default to bcrypt and support Argon2. If you inherit a system that stores MD5 or SHA-1 password hashes, plan a migration that re-hashes each password with a proper algorithm the next time its owner logs in.

Privacy, encodings and getting consistent results

All hashing on this page happens in your browser. SHA hashes and SHA-based HMACs use the Web Crypto API built into modern browsers, and MD5, which Web Crypto does not offer, is calculated by a small JavaScript implementation checked against the standard RFC 1321 test values. Nothing you type or choose is uploaded, logged or stored, and the values disappear when you leave the page.

If your hash does not match another tool, the input is almost always slightly different. Text here is encoded as UTF-8, which is the norm on the web, but some older systems use other encodings, so accented letters and symbols can produce different bytes. Line endings are another common cause: a file saved on Windows usually ends lines with a carriage return and line feed, while text pasted into a browser box uses line feeds only. Trailing spaces and a final new line also change the result, which is why hashing a file directly is more reliable than copying its contents into the text box.

Examples you can copy

MD5      900150983cd24fb0d6963f7d28e17f72
SHA-1    a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Windows PowerShell:  Get-FileHash .\installer.exe -Algorithm SHA256
Windows cmd:         certutil -hashfile installer.exe SHA256
macOS:               shasum -a 256 installer.dmg
Linux:               sha256sum installer.iso

$expected = hash_hmac('sha256', $rawBody, $secret);
if (! hash_equals($expected, $signatureHeader)) {
    abort(401);
}

Common mistakes to avoid

Frequently asked questions