Skip to content
Reembun
Hash generator icon
Developer

Hash generator

Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashes from text or any file, computed entirely on your device.


MD5Broken for security. Fine as a checksum, never for passwords or signatures.
not computed yet
SHA-1Collision attacks are practical. Avoid for anything security-related.
not computed yet
SHA-256
not computed yet
SHA-384
not computed yet
SHA-512
not computed yet

Ready. Runs locally on your device.

Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.

Share

Share this page

Share result

Your results

Use the tool above first. Whatever it works out shows up here, ready to copy or share.

Cite

Cite this page

Reembun. (2026, July 27). Hash generator. https://reembun.com/hash-generator
Pick a style, then copy the reference. The access date is today.

How to use it

  1. Choose text or a file

    Type or paste into the box, or switch to File and pick one. Either way the hashing happens in this tab.

  2. Read every digest at once

    MD5, SHA-1, SHA-256, SHA-384 and SHA-512 are produced together for the same input, so you can match whichever the other side published.

  3. Match the case

    Uppercase flips the hex output, which matters when you are comparing by eye against a checksum printed in capitals.

  4. Copy the one you need

    Each digest has its own copy button. For file integrity, prefer SHA-256; MD5 and SHA-1 are there for old checksums, not for security.

What a hash function does

A cryptographic hash maps input of any length to a fixed-length output, with three properties that make it useful:

  1. Deterministic: the same input always gives the same digest.
  2. One-way: recovering the input from the digest is computationally infeasible.
  3. Avalanche: changing one bit of input changes roughly half the output bits.

That third property is what makes hashes useful for integrity checking. A single altered byte anywhere in a 4 GB file produces a completely different digest:

"hello"  → 5d41402abc4b2a76b9719d911017c592
"hellp"  → 84b52b8afc1e35b2a7d99b5a6f8b1eb1

The algorithms

AlgorithmOutputStatus
MD5128 bits, 32 hex charsBroken. Checksums only
SHA-1160 bits, 40 hex charsBroken. Being removed everywhere
SHA-256256 bits, 64 hex charsSecure. The current default
SHA-384384 bits, 96 hex charsSecure
SHA-512512 bits, 128 hex charsSecure. Faster than SHA-256 on 64-bit CPUs

SHA-256, SHA-384 and SHA-512 are computed by your browser’s own native, audited implementation. Browsers deliberately leave MD5 out to discourage its use, so that one algorithm alone is handled separately.

Verifying a download

The most common legitimate use. A project publishes the SHA-256 of its installer; you compute it locally and compare.

  1. Download the file.
  2. Drop it into the File tab above.
  3. Compare the SHA-256 against the published value.

This detects corruption during transfer, and detects tampering only if you obtained the published hash through a channel the attacker does not control. A checksum listed on the same compromised page as the download proves nothing. Signed release manifests exist for this reason.

Comparing by eye, check the first and last six characters and the length. Anything engineered to fool you will match a prefix.

Why “broken” still ships

MD5 and SHA-1 remain widespread in Git object addressing, older package managers and file deduplication. That is not always negligence: collision attacks require an adversary who can choose both inputs. Against accidental corruption, whether a bad disk or a truncated download, MD5 is still perfectly effective.

The line is whether an adversary is in the picture. Detecting a corrupted download: fine. Signing anything, verifying identity, or storing credentials: never.

Hashing passwords

Password storage needs the opposite of a fast hash. Argon2id is the current recommendation, with scrypt and bcrypt as established alternatives. Each is deliberately expensive in time and memory, and each takes a unique random salt per password so identical passwords do not produce identical digests.

Never store a password as SHA-256, salted or not. The salt stops precomputed table lookups, but does nothing about the fact that a modern GPU can test billions of candidates per second.

Common questions

Can a hash be reversed?

Not by inverting it, since hashes are one-way by design. But short or common inputs can be found by brute force or looked up in precomputed tables. An MD5 of a six-character password is effectively public knowledge. Hashing is not encryption and gives no confidentiality.

Is MD5 broken?

For security, completely. Practical collision attacks have existed since 2004 and can now be performed in seconds, and chosen-prefix collisions were demonstrated against SHA-1 in 2017 and again more cheaply in 2020. Both remain acceptable as non-adversarial integrity checks, such as verifying a file downloaded correctly, but must never be used for signatures, certificates or passwords.

Why can I not compute an MD5 of a huge file?

The file is read fully into memory to hash it, so very large files can exhaust what the browser tab is allowed to allocate. In practice files up to a couple of gigabytes usually work on a desktop; phones have far less headroom. If it fails, that is the reason.

Should I hash passwords with SHA-256?

No. Fast hashes are the wrong tool for passwords precisely because they are fast: a GPU can compute billions of SHA-256 hashes per second. Use a deliberately slow, memory-hard algorithm designed for the job, such as Argon2id, scrypt or bcrypt, each with a per-password salt.

Last reviewed