Hash Generator

Hashing the Same String Four Ways

Type the word hello into the input and all four algorithms compute simultaneously, which makes it easy to see how differently each one represents the exact same five bytes. MD5 produces 5d41402abc4b2a76b9719d911017c592 — a 128-bit digest shown as 32 hex characters. SHA-1 produces aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, a 160-bit digest as 40 hex characters. SHA-256 produces 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, 256 bits as 64 hex characters, and SHA-512 produces a 512-bit, 128-character digest. Change a single character — hash Hello with a capital H instead — and every one of the four outputs changes completely and unpredictably; there is no partial resemblance between the two digests despite the inputs differing by one bit of case. That total unpredictability from a tiny input change, known as the avalanche effect, is precisely what makes a hash useful for detecting even the smallest corruption or tampering.

The Same Job With sha256sum and openssl

Everything this page computes has a direct terminal equivalent. On Linux, echo -n "hello" | sha256sum produces the same SHA-256 digest shown above; on macOS, the equivalent is echo -n "hello" | shasum -a 256. For file hashing rather than a typed string, sha256sum myfile.tar.gz or shasum -a 256 myfile.tar.gz reads the file directly. The openssl CLI covers all four algorithms this tool supports through one interface: openssl dgst -md5, -sha1, -sha256, and -sha512 flags select the algorithm. On Windows, PowerShell's Get-FileHash -Algorithm SHA256 does the same job natively without needing WSL or a separate install. This tool is functionally a browser wrapper around the identical algorithms these commands implement — a file hashed here and the same file hashed with sha256sum will always produce byte-identical digests, which is exactly what makes browser-based verification trustworthy against a checksum published by any other tool.

Hash vs HMAC vs Encryption

These three cryptographic primitives get confused constantly, and the confusion matters because using the wrong one is a real security mistake, not just a terminology slip. A plain hash like SHA-256 is a one-way fingerprint with no secret involved — anyone can compute the identical hash from the identical input, which makes it useful for integrity checks but useless for proving who produced the data, since an attacker can simply recompute a matching hash over tampered content. HMAC solves that specific gap by mixing a shared secret key into the hashing process, so only someone who knows the secret can produce or verify a valid tag — the right primitive when authenticity of origin matters, such as confirming a webhook genuinely came from the platform claiming to have sent it. Encryption is a different job entirely: hashing is one-way and irreversible by design, while encryption is reversible and exists to keep data confidential rather than to fingerprint it. Hashing a password and encrypting a password serve opposite goals, and conflating them — for instance, "encrypting" a password for storage instead of hashing it with a slow, salted algorithm — is a recurring, serious mistake in application security reviews.

Why MD5 and SHA-1 Still Show Up Here

Both MD5 and SHA-1 are cryptographically broken for any purpose that assumes an adversary is actively trying to defeat them. Researchers published practical MD5 collision techniques in 2004, and a full SHA-1 collision was publicly demonstrated in 2017, meaning an attacker can deliberately construct two different inputs that hash to the same value — which completely undermines any use case relying on a hash being unforgeable, such as digital signatures, TLS certificate fingerprints, or password storage. Neither algorithm should be used for anything security-critical today; SHA-256 or SHA-512 are the correct choice whenever an adversary might be motivated to forge a matching hash. They remain in this tool because plenty of legitimate, non-adversarial use cases still specify them by convention — older package registries, some embedded system checksums, and cache-key generation where nobody is trying to engineer a collision — and being able to compute them without installing separate legacy tooling is still a genuine, if narrowing, need.

Where Hashes Show Up in Daily DevOps Work

• Download verification: hash a downloaded binary or archive and compare it against the checksum published on the software's release page to confirm it wasn't corrupted or tampered with in transit.
• Container image digests: Docker and Kubernetes identify image layers and manifests by SHA-256 digest, so understanding what that digest represents is directly relevant to debugging a pull failure or a digest mismatch.
• Content-addressed identifiers: generate a SHA-256 hash of a config file or build artifact to create a stable identifier that changes automatically, and only, when the content changes.
• Package integrity checks: npm, pip, and Homebrew all publish SHA-256 checksums so a package manager can verify a downloaded artifact matches exactly what the registry published before installing it.

Frequently Asked Questions