Hash Generator

Hashing is one-way — it is not encryption

A cryptographic hash is a one-way function: it maps an input of any size to a fixed-length fingerprint (256 bits for SHA-256) and is designed so you cannot run it backwards. This is the single most misunderstood point in the field. Encryption is reversible by anyone with the key; hashing is reversible by no one. There is no 'dehash' operation, and any site claiming to reverse a hash is really just looking the value up in a precomputed table of common inputs. If you need to get the original data back, you want encryption like AES-GCM, not a hash.

What a good hash guarantees is determinism and collision resistance: the same input always yields the same digest, a one-character change produces a completely different digest (the avalanche effect), and it is computationally infeasible to find two inputs that hash to the same value. Those three properties are what make hashes useful for integrity, deduplication and fingerprinting — none of which require ever recovering the input.

The everyday job: integrity and checksums

The most common honest use of a hash is verifying that a file arrived intact and unaltered. A Linux ISO, a wallet binary or a backup is published alongside its SHA-256 digest; you hash your downloaded copy and compare. If even one byte changed in transit — a truncated download, a corrupted disk, a tampered mirror — the digests differ and you know not to trust the file. This is why package managers, Git (which names every object by its hash) and software-signing pipelines lean on hashing so heavily.

For this to mean anything, the reference digest must come from a trustworthy channel. A checksum hosted on the same server as the file it describes only catches accidental corruption, not a deliberate swap — an attacker who replaced the file would simply update the checksum too. Integrity hashing detects tampering only when the expected value reaches you independently of the file.

Why MD5 and SHA-1 are broken for security

MD5 and SHA-1 still appear everywhere, but their collision resistance is gone. Researchers can now construct two different files with the same MD5 in seconds and the same SHA-1 in hours of GPU time — the 2017 SHAttered attack produced two distinct PDFs sharing one SHA-1 digest, and the cost has only fallen since. Once collisions are cheap, a digest can no longer prove a file is the file you expected, which defeats the entire point of a security checksum or a signature.

• Safe to keep using MD5/SHA-1 for: non-adversarial integrity such as detecting accidental disk corruption, cache keys, or deduplicating your own files where no attacker is involved.
• Do not use them for: digital signatures, certificate fingerprints, verifying downloads against tampering, or anything where a motivated party could supply a colliding input.
• Use SHA-256 (or SHA-3 / BLAKE2) as the default for any security-relevant fingerprint — it has no known practical collisions.
• A longer digest is not automatically safer: SHA-1 is 160 bits and still broken. The algorithm's design, not its output length, is what failed.

Passwords need a password hash, not a fast one

Storing passwords as raw SHA-256 is a classic mistake. General-purpose hashes are built to be fast, which is exactly wrong for passwords: speed lets an attacker who steals your database test billions of guesses per second. Two defences are non-negotiable. First, a unique random salt per password, so identical passwords produce different hashes and precomputed rainbow tables are useless. Second, a deliberately slow, memory-hard algorithm — bcrypt, scrypt or Argon2 — that is tuned to take a fraction of a second per hash, turning a billion-guess-per-second attack into thousands.

In short, use SHA-256 to fingerprint data and a purpose-built password hash to store credentials; they are different jobs. This tool is for the former — file and text fingerprinting, integrity checks, content addressing. It deliberately is not a password-storage system, and the digest it shows you should never be what lands in your users table. For the reasoning behind strong human secrets, see Password security in 2026.