Generate a hash

No. The file is read on your own device and hashed there by the browser's built-in cryptography, the same code that handles HTTPS. Nothing is uploaded, so there is no upload cap and no waiting on a connection.

Your device's memory, not an upload cap. The browser's cryptography has no way to hash a file in pieces — it needs the whole file in memory at once — so a very large file (a DVD image, say) may fail on a machine that cannot hold it. Files up to a few hundred megabytes are fine on a normal computer. If a large one fails, that is the limit you have hit, and the page says so rather than hanging.

SHA-256 for anything new. It is the modern default, it is what software checksums, container digests and blockchain systems use, and it has no known weaknesses. Use MD5 or SHA-1 only when something else requires them — matching an old published checksum, a legacy system, or Git, which identifies objects by SHA-1. Use SHA-512 when you specifically want a longer digest; on 64-bit machines it is often faster than SHA-256, not slower.

You can, but you should not store the result. This is the single most common mistake in this area, so it is worth being direct: MD5, SHA-1 and SHA-256 are all wrong for passwords, and SHA-256 being cryptographically strong does not help. The problem is that these functions are FAST by design — a modern graphics card computes billions of SHA-256 hashes per second, so a stolen database of SHA-256 password hashes is cracked at enormous speed. Passwords need a deliberately slow, salted function built for the job: bcrypt, scrypt or Argon2. Every serious framework has one built in.

Because anyone can now construct two different files with the same MD5 hash, on ordinary hardware, in seconds. That has been true since 2004 and it has been demonstrated with real, working consequences — two PDFs showing different contracts, two executables where one is malware. So MD5 cannot prove a file is the file you expected; a deliberate forgery can match. It is still perfectly reasonable for detecting accidental corruption, like a bad download or a truncated copy, which is what most published MD5 checksums are actually for. It must never be used for security.

For the same reason, more recently. In 2017 Google and CWI produced two different PDFs with the same SHA-1 hash, and by 2020 the attack was cheap enough to forge signatures with. Browsers stopped accepting SHA-1 certificates years ago, and Git is migrating away from it. If you are choosing an algorithm today, choose SHA-256.

Drop the downloaded file in, then paste the checksum from the site you got it from into the comparison box. If they match, the file arrived intact and is the file that was published. If they do not, delete it and download again. Two cautions: get the checksum from the official source rather than from wherever you got the file, and remember that a checksum only proves the file matches what that page published — if the page itself was compromised, both will match.

SHA-1, SHA-256, SHA-384 and SHA-512 come from the browser's own Web Crypto implementation, the same code that handles HTTPS. MD5 is not in Web Crypto — deliberately, because it is broken — so it is implemented here directly from RFC 1321 and checked against that document's own published test vectors.