Hash Generator (MD5, SHA-1, SHA-256, SHA-384, SHA-512)

What a hash does and doesn't do

A cryptographic hash takes any input — a word, a file, a billion-byte database dump — and produces a fixed-length fingerprint. The same input always produces the same hash, but you cannot reverse a hash to get the original input. This makes hashes useful for:

• Verifying file integrity — download a file with its SHA-256 published alongside, hash your copy, compare.
• Password storage — never store raw passwords; store a salted hash (using bcrypt/scrypt/Argon2, not raw SHA).
• Deduplication — files with the same hash are (almost certainly) identical content.
• Cryptographic signing — hash the document, sign the hash. Faster than signing the whole document.

Algorithm choices and when to use them

What hashing actually does

A cryptographic hash function takes an input of any size and produces a fixed-size output — a "hash" or "digest" that represents the input in a compact form. The same input always produces the same output. Different inputs produce completely different outputs, even if they differ by a single bit. And given only the output, you can't reasonably reverse-engineer the input. Those three properties — determinism, avalanche behavior, and one-way irreversibility — are what make hashes useful.

The main uses I hit in real admin work: checking file integrity after a download, verifying that two systems have the same version of a config file, and generating stable identifiers for things that don't have their own IDs. Occasionally password hashing, though for real password storage you want a purpose-built KDF like Argon2 or bcrypt rather than a raw hash function.

The functions this tool implements, and when to use each

MD5

The oldest and weakest of the common hash functions. Produces a 128-bit output (32 hex characters). Was standard for decades. Now broken for security purposes — collisions can be manufactured, meaning an attacker can find two different inputs that produce the same MD5 output. Any use of MD5 for security-sensitive purposes is a finding in a modern audit.

MD5 is still fine for non-security uses: file integrity checks against accidental corruption (not against an attacker), quick deduplication of large content, generating short stable identifiers where collision resistance doesn't matter. I use it occasionally for tagging files in scripts where I need a fixed-size identifier and don't care about attacks. But nothing I care about the security of.

SHA-1

Produces 160 bits (40 hex characters). Was the successor to MD5. Also broken now — Google published a real-world SHA-1 collision in 2017 (SHAttered), and the cost of finding collisions has continued to drop. Git famously uses SHA-1 internally, which caused some drama when the collision was published, though in practice Git's usage patterns make exploitation impractical.

Like MD5, SHA-1 is fine for non-security integrity checks. Not fine for anything where an attacker might benefit from producing a collision. Still commonly seen in older systems and file distributions.

SHA-256

Part of the SHA-2 family. Produces 256 bits (64 hex characters). The current standard for most integrity and identification uses. TLS certificates use SHA-256 signatures. Bitcoin uses SHA-256. Most software distribution channels publish SHA-256 sums for downloads. If you don't have a specific reason to use something else, SHA-256 is the default.

SHA-256 is not broken and is expected to remain secure for the foreseeable future. Quantum computers might eventually reduce its effective strength, but the practical impact on hash security is much smaller than on public-key crypto, and SHA-256 is still expected to hold up.

SHA-384 and SHA-512

Also SHA-2 family, but with larger outputs (384 and 512 bits respectively). SHA-512 is not just a longer SHA-256 — it's a different algorithm optimized for 64-bit systems. Runs faster than SHA-256 on 64-bit hardware, slower on 32-bit.

SHA-512 is worth using for very-long-lived security where you want extra margin. SHA-384 is used specifically in some standards (TLS 1.3's ECDHE_SHA384 cipher suite, for example) but is less common outside those contexts.

Where I actually use hashes in admin work

Verifying downloads

When I download an OS image, a firmware update, or any large file that matters, I check the published hash. The publisher includes a SHA-256 sum on the download page. After downloading, I compute the SHA-256 of the file I got and compare. If they match, the file survived the network intact. If they don't, either the download was corrupted or someone tampered with it in transit.

This catches accidental corruption from CDN edge cases, disk errors, and bad transfers. It doesn't help if you're getting the hash from the same page as the file (an attacker who compromised the download server would just update both). For real integrity assurance, you need the hash from a separate trust path — sometimes signed with a maintainer's key, sometimes distributed through a separate channel.

Comparing config files across systems

When I'm maintaining configuration across multiple similar servers, sometimes I need to confirm two files are byte-for-byte identical without comparing them character by character. Hashing both and comparing the hashes is the fast way. If the hashes match, the files are identical. If they don't, something diverged.

Generating stable identifiers

Sometimes I need an identifier for a thing that doesn't have its own natural ID. Hashing a canonical description of the thing gives me a stable identifier that will be the same next time I hash the same input. Useful for cache keys, correlation IDs across systems, and deduplication.

The hash doesn't have to be cryptographically strong for this — MD5 or even a simpler non-cryptographic hash like MurmurHash or xxHash works fine and is faster. But since I usually have SHA-256 available and don't care about the speed difference, that's what I use by default.

Detecting duplicate files

When cleaning up a customer's file server, hashing every file and grouping by hash reveals duplicates. Files with the same content produce the same hash regardless of filename. This turns duplicate detection into a straightforward sort-and-group operation on a list of (path, hash) pairs.

What hashes cannot do

Encrypt data

Hashes are one-way. You can compute the hash of a file, but you can't reverse a hash back into the original file. For confidentiality (keeping data secret), you need actual encryption — AES, ChaCha20, etc.

Protect passwords by themselves

Raw hash functions are too fast for password protection. Modern password cracking rigs can compute billions of SHA-256 hashes per second, which means an attacker with a stolen password database can try billions of guesses per second. For real password protection, use a purpose-built password hashing function that's deliberately slow and memory-hard: Argon2, scrypt, or bcrypt.

The functions on this page (SHA-256, etc.) are the wrong tool for password storage. Right tools include: bcrypt (still fine, well-tested), scrypt (memory-hard, good), Argon2 (modern winner, best if your framework supports it).

Prove authorship or origin

A hash proves the data hasn't changed, but doesn't say anything about who created it. For proving authorship you need a digital signature (RSA, ECDSA, EdDSA) that ties the data to a private key held by the author.

Common misconceptions

"MD5 is fine for X"

If X involves any adversarial context — an attacker who benefits from producing collisions — MD5 is not fine. If X is purely about accidental corruption, MD5 is fine. Most people use "adversarial" loosely and MD5 usage tends to be a red flag anyway.

"Longer hash = more secure"

For collision resistance, yes — a longer hash has more possible outputs and is harder to force a collision on. But once you're past 256 bits, the practical difference is minimal. SHA-256 is expected to remain secure for decades. Using SHA-512 doesn't meaningfully add security for most uses; it just uses more space.

"Hashes are unique"

Only probabilistically. Two different inputs producing the same hash is called a collision. For a well-designed hash of N bits, finding a collision by brute force takes about 2^(N/2) attempts. For SHA-256, that's 2^128 — beyond feasible with any conceivable computer. For MD5, it's 2^64, which is well within modern computing capability.

"I can identify a file by its hash without seeing it"

You can verify a file's identity by its hash. You cannot recover a file from just its hash. If someone tells you "here's the hash of my private key," you cannot reconstruct the private key from that.

Related tools

If you're working with certificates or JWTs, hash functions are involved in the signature algorithms. The SSL/TLS Cert Inspector shows the certificate's signature algorithm (typically SHA-256 in modern certs). The JWT Decoder shows the signing algorithm from the token header.

For encoding hash output (or other binary data) into text-safe formats, the Base64 Encode/Decode tool handles both standard and URL-safe encoding.

Privacy

Hashing happens entirely in your browser using the Web Crypto API. Nothing you paste is sent to any server. Passwords, keys, sensitive documents — whatever you hash stays local. You can verify this by opening browser developer tools before running a hash and confirming no network activity when you click compute.