How to Generate a Hash (SHA-256, SHA-512 & More)

You need a hash. Maybe a download page listed a long hex string labelled "SHA-256" and you want to check your file matches. Maybe you're storing a fingerprint of some data so you can detect if it changes later. Maybe a tutorial told you to "hash it" and didn't explain what that means.

Whatever brought you here, generating one takes about three seconds. Open the free FileNaut Hash Generator, type or paste your text, and you'll immediately see four hashes at once — SHA-1, SHA-256, SHA-384 and SHA-512 — each with its own copy button. Nothing is uploaded. The hashing runs in your browser through the built-in Web Crypto API, so your input never leaves your device.

This guide covers how to generate a hash online and on the command line, what a hash actually is, which algorithm you should use in 2026 (and which two you should stop using), how to verify a file checksum, and the single most common reason your hash doesn't match the one you're comparing it to.

A hash function takes any input — three letters or a three-gigabyte file — and produces a fixed-length string of characters called a hash, digest, or checksum. It's a fingerprint for data.

Four properties make hashes useful:

1. Deterministic. The same input always produces the same hash. Every time, on every machine, forever. SHA-256 of hello is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 on your laptop and on a server in Singapore.
2. Fixed length. The output size depends only on the algorithm, never on the input. SHA-256 always returns 64 hex characters — whether you hash one letter or an entire film.
3. One-way. You cannot reverse a hash back into the original data. There's no "unhash" button, and any site offering one is really just looking your hash up in a database of pre-computed common inputs.
4. Avalanche effect. Change one bit of input and roughly half the output bits flip. Watch what a single capital letter does:

hello  →  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Hello  →  185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

That's why hashes work as tamper detection. Any change at all — a flipped bit from a corrupted download, a single edited character, a hidden payload injected into an installer — produces a completely unrecognisable hash.

1. Open the free FileNaut Hash Generator. No signup, no install, no upload.
2. Type or paste your text into the input box.
3. Hashes appear instantly as you type — there's no "generate" button to press. You get all four algorithms simultaneously: SHA-1, SHA-256, SHA-384 and SHA-512.
4. Find the algorithm you need and click Copy next to it. The hash goes straight to your clipboard.
5. Paste it wherever you need to compare or store it.

Because all four are generated at once, you don't need to know in advance which one you want — useful when a download page says "SHA512" but your notes say "SHA-256". Just copy the one that matches.

Two honest limitations worth knowing up front:

• It hashes text, not files. To checksum a downloaded ISO or installer, use the command line — one line, covered in Section 6 below.
• No MD5. Browsers deliberately don't expose MD5 through the Web Crypto API, because it's been cryptographically broken for two decades. If a download page only publishes an MD5 checksum, Section 6 shows you the command for that too.

Short answer: SHA-256. It's the modern default, it's fast, it's supported everywhere, and nobody has broken it. Use something else only when you have a specific reason.

Why MD5 and SHA-1 are "broken": both suffer from practical collisions — researchers can construct two different inputs that produce the identical hash. MD5 collisions have been trivial since 2004 and were used in the wild by the Flame malware to forge a Microsoft code-signing certificate. SHA-1 fell in 2017 when Google and CWI Amsterdam produced two different PDFs with the same SHA-1, and by 2020 a chosen-prefix collision cost roughly $45,000 of compute. NIST formally deprecated SHA-1 in December 2022.

That matters for security. It does not mean MD5 is useless — it's still perfectly fine for detecting accidental corruption, where nobody is deliberately crafting a collision. Just never use it to prove a file wasn't tampered with by an attacker.

These three get mixed up constantly, and the confusion causes real security bugs. The difference is simple:

The critical takeaway: encoding is not security. Base64 is a reversible transformation anyone can undo in one click — our Base64 encoding guide covers this in depth, and it's exactly why the payload of a JSON Web Token is readable by anyone holding the token. If you need secrecy, encrypt. If you need to detect changes, hash. If you just need to move binary data through a text field, encode.

Verifying a downloaded file is the most common real-world reason to generate a hash. The publisher lists the expected checksum on their site; you hash your copy and compare. If they match, your download is complete and unmodified. Since file hashing needs the file itself, use your operating system's built-in command:

Get-FileHash uses SHA-256 by default; add -Algorithm SHA512 or -Algorithm SHA1 to switch. On macOS and Linux, swap 256 for 512 in the shasum -a flag.

How to actually compare them: don't eyeball 64 hex characters — humans are terrible at this and attackers know it. Either paste both strings into our Text Compare tool to see any difference highlighted (see the file comparison guide), or use Ctrl+F on the page and search for the first eight characters of your computed hash. If the publisher's checksum contains it, you're almost certainly fine.

One safety note that gets overlooked: a checksum only protects you if it came from a different, trusted source than the file. If an attacker controls the download page, they control the checksum listed on it too. Checksums published on an official HTTPS site, a signed release note, or a separate mirror are meaningful; a checksum sitting next to the file on a random mirror is theatre.

This is the most consequential mistake people make after learning what hashing is, so it gets its own section.

Hashing passwords is correct. Hashing them with SHA-256 is not. The reason is counterintuitive: SHA-256 is too fast. It's engineered for speed, and a consumer GPU can compute billions of SHA-256 hashes per second. If your database leaks, an attacker runs every common password, every dictionary word and every leaked-password list through SHA-256 and matches them against your stored hashes in hours. Unsalted hashes fall even faster to precomputed rainbow tables.

Password hashing needs a deliberately slow, salted algorithm:

• Argon2id — winner of the Password Hashing Competition and the current OWASP first choice. Memory-hard, which blunts GPU attacks.
• bcrypt — battle-tested, available in every language, still a solid choice.
• scrypt or PBKDF2 — acceptable where the first two aren't available; PBKDF2 is often required for compliance reasons.

All of them salt automatically (a unique random value per password, so identical passwords produce different hashes) and let you tune a work factor upward as hardware gets faster. Use a maintained library — never hand-roll this.

Where SHA-256 is right: file integrity, digital signatures, data fingerprinting, deduplication, blockchain, HMAC message authentication, and generating unique identifiers. And if you're choosing a password rather than storing one, our Password Generator and the strong password guide cover the other half of the problem.

You hashed the same thing twice and got two different answers. Almost always one of these five:

1. A trailing newline. The single biggest culprit. Terminal echo appends a newline character, which is part of the input and changes everything:

   printf '%s' "hello" | shasum -a 256   →  2cf24dba5fb0a30e26e83b2ac5b9e29e1...
   echo "hello"        | shasum -a 256   →  5891b5b522d5df086d0ff0b110fbd9d2...

   Use printf '%s' or echo -n to match what a text box gives you.
2. Invisible whitespace. A trailing space, a tab, or a Windows \r\n line ending versus a Unix \n — all different bytes, all different hashes.
3. Different algorithms. Count the characters: 32 = MD5, 40 = SHA-1, 64 = SHA-256, 96 = SHA-384, 128 = SHA-512. If the lengths differ, you're comparing different algorithms, not different data.
4. Uppercase vs lowercase hex. Some tools print A4F9, others a4f9. Same hash, different formatting — lowercase both before comparing.
5. Text encoding. Non-ASCII characters (accents, emoji, curly quotes) hash differently depending on encoding. FileNaut hashes UTF-8; a tool using UTF-16 or Latin-1 produces a different result for the same visible characters.

An easy sanity check: hash an empty input. SHA-256 of nothing at all is always e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. If two tools agree on that, they agree on the algorithm, and your mismatch is coming from the input.

• Default to SHA-256 unless something specifically requires another algorithm. It's the right answer roughly 90% of the time.
• Never paste sensitive data into a server-side hasher. If a site processes your input on its server, you've just shared it. FileNaut's generator runs entirely in your browser through the Web Crypto API — a good habit to require of any online tool handling data you care about.
• A longer hash isn't automatically better. SHA-512 offers no practical security advantage over SHA-256 today; it's mainly useful for long-horizon integrity and can be faster on 64-bit hardware. Don't switch just because the number is bigger.
• Hashes are fingerprints, not storage. You cannot recover data from its hash. If you hash something and lose the original, it's gone.
• Store the algorithm alongside the hash. A bare hex string six months from now is a puzzle. sha256:2cf24dba... is a record.
• Need a unique identifier rather than a fingerprint? Use a UUID instead — hashes are for verifying content, UUIDs for naming things (guide here).