Hash Generator

What a hash function actually does

A cryptographic hash function takes any sequence of bytes, a two-letter string or a 40 GB disk image, and reduces it to a fixed-length value called a digest. The same input always produces the same digest, and changing a single bit of the input scrambles the whole output. That second property, the avalanche effect, is what makes a digest useful as a fingerprint: two files that differ anywhere will disagree immediately, and you can compare a 64-character line instead of comparing gigabytes.

The security of the design rests on being hard to run backwards. Given a digest, there should be no way to recover the input short of guessing, and it should be infeasible to find two different inputs that share one digest. When researchers say a hash is broken, they mean that second guarantee has fallen: collisions can be produced on purpose, so a digest no longer proves which file you have. That is exactly what happened to MD5 and then to SHA-1.

Which of the 21 algorithms to choose

The list on this page is deliberately long because the algorithms serve different jobs, and picking by name recognition tends to pick badly. The groups below are the practical division.

Digest length is not a quality score. SHA-512 is not twice as trustworthy as SHA-256, and a longer digest mostly buys resistance to brute-force search that SHA-256 already provides comfortably. On 64-bit processors SHA-512 is often the faster of the two, which is a better reason to pick it than the number in the name.

Verifying a download, step by step

The everyday use for this tool is checking that a file you downloaded matches what the publisher released. Find the checksum the project published, note which algorithm it used, drop your copy of the file into the tool, select that algorithm, and compare the two strings. They match or they do not: there is no partial credit, and a single differing character means the files differ.

Two caveats are worth internalising. First, comparison is case-insensitive, because hexadecimal digests are printed in either case. Second, and more important, a checksum sitting next to a download link only proves the transfer was not corrupted. If the server itself was compromised, whoever replaced the file also replaced the checksum beside it. Guarding against that needs a cryptographic signature checked against a public key you obtained independently, which is what GPG signatures on release files are for.

Hashing happens in your browser

Nothing you type or select is transmitted anywhere. The algorithms are compiled to WebAssembly and run in the page, and files are streamed through the hasher in 64 MB chunks using the browser's File API, so memory use stays flat whether the input is a text snippet or a disk image. There is no server-side component to receive your data, which means you can hash a private key, an internal document, or a database dump without it leaving the machine. If you would rather verify that claim than trust it, open your browser's network panel while hashing, or turn off networking first: the tool keeps working.

Selecting fewer algorithms is faster, since each selected algorithm reads the whole input. For large files, start with the one algorithm you need. The rest of the InToolbox collection follows the same in-browser rule, and the privacy policy spells out the handful of exceptions that need live data from an outside API.

Mistakes that waste an afternoon

The commonest is an invisible trailing newline. Editors add one when saving, so hashing a file and hashing the text you copied out of it can legitimately disagree. Encoding is the second: a string is only a sequence of bytes once you choose an encoding, and UTF-8 and UTF-16 produce different bytes and therefore different digests. The third is treating a hash as encryption. Hashing is one-way and has no key, so it hides nothing that an attacker can guess and try. If you need to recover the original later, you want encryption, not a digest.

Frequently asked questions

Is MD5 still safe to use?

Not for anything security related. Practical collision attacks against MD5 have been public since 2004, so two different files can be crafted to share one MD5 digest. It is fine as a fast integrity check against accidental corruption, and it is still the only checksum some older projects publish, which is why the tool keeps it. Never use it to verify that a download has not been tampered with deliberately, and never use it in a signature.

Which hash should I use to verify a download?

Use whichever algorithm the publisher used, because you can only compare like with like. If the project publishes a SHA-256 line, compute SHA-256. If you get to choose, SHA-256 is the safe default: it is fast enough, universally supported, and has no known practical weaknesses. Remember that a checksum published on the same page as the file only protects against a corrupted transfer. Protection against a compromised server needs a signature you can verify against a key you already trust.

Can a hash be reversed back into the original text?

No. A hash function throws information away, so there is no inverse to compute: any digest has infinitely many possible inputs. What attackers do instead is guess. They hash enormous dictionaries of likely inputs and look for a match, which is why short passwords, common phrases, and low-entropy values such as phone numbers or dates fall instantly to a rainbow table. A hash of a predictable value is not a secret.

Are my files uploaded to a server?

No. The hashing runs in a WebAssembly module inside the browser tab. Files are read from disk in 64 MB chunks with the browser File API and fed through the hasher incrementally, so the bytes never touch the network and never need to fit in memory at once. You can confirm it by opening your browser's network panel while hashing, or by disconnecting from the network entirely and hashing anyway.

Why include CRC32, Adler32 and xxHash if they are not secure?

Because integrity and security are different jobs. CRC32 and Adler32 are error-detecting codes designed to catch accidental damage such as a flipped bit in transit, and they are what formats like ZIP, PNG and Gzip actually store. xxHash and BLAKE3 are extremely fast non-cryptographic or modern cryptographic hashes used for deduplication, cache keys, hash tables and file synchronisation. They are the right tool when speed matters and no adversary is involved.

Should I use this to hash passwords before storing them?

No. Plain hashes are the wrong primitive for passwords precisely because they are fast: a GPU can try billions of SHA-256 guesses per second. Password storage needs a deliberately slow, salted, memory-hard function such as Argon2id, scrypt or bcrypt, with a per-user salt and a tuned cost parameter. Use your platform's password hashing library and do not build the scheme yourself.

Why does another tool give a different hash for the same text?

Almost always because the input differs by something invisible. A trailing newline appended by a text editor changes the digest completely. So does a different character encoding: UTF-8 and UTF-16 produce different bytes for the same visible characters, and hashes operate on bytes. Digest casing is another red herring, since the same value can be printed as lowercase or uppercase hexadecimal. Compare case-insensitively before concluding anything is wrong.

What is the practical difference between SHA-2 and SHA-3?

SHA-2 (SHA-224 through SHA-512) and SHA-3 are both current NIST standards and both are considered secure. They are built on entirely different internal designs, SHA-2 on a Merkle-Damgard construction and SHA-3 on the Keccak sponge, which is the point: if a structural break were ever found in one family, the other would not inherit it. SHA-2 remains the pragmatic default because it is faster in most software and supported everywhere. SHA-3 is a hedge and a requirement in some newer specifications.

How large a file can this handle?

Multi-gigabyte files are fine. Because the file is streamed through the hasher in 64 MB chunks rather than loaded whole, memory use stays flat regardless of file size and the limit is your patience rather than your RAM. Throughput depends on the algorithm and your CPU: BLAKE3 and xxHash are typically an order of magnitude faster than SHA-512, and selecting fewer algorithms at once finishes sooner.