Hash Generator — MD5, SHA-1, SHA-256 & SHA-512

A hash generator turns any piece of text — a password, a file's contents, a config string, an API payload — into a fixed-length string of characters called a hash, or digest. Feed it the same input twice and you get the identical hash every time; change even one character and the entire output looks completely different. That property makes hashing the backbone of integrity checks, deduplication, password storage, and digital signatures across nearly every corner of software engineering.

This tool computes MD5, SHA-1, SHA-256, and SHA-512 hashes directly in your browser, using the Web Crypto API for the SHA family and a compact JavaScript implementation for MD5, so nothing you type ever leaves your device. Arb Digital's engineers use hash generators constantly — verifying downloaded files, checking deployment artifacts, generating cache keys — and we built this version to be fast, accurate, and trustworthy for that same everyday work.

What This Hash Generator Does

Type or paste text into the box, choose which algorithms you want, and click Generate Hashes. The tool computes the selected digests and displays each as a lowercase hexadecimal string in its own copyable field. You can select any combination of MD5, SHA-1, SHA-256, and SHA-512, and the calculation re-runs live so you can compare how the same input behaves across algorithms — useful when you're verifying a checksum a vendor published in a specific format, or when a spec asks for one algorithm and you need to confirm your output matches.

How to Use It

1. Enter your text. Type directly or paste from anywhere — a file's text contents, a string literal from code, a password you're testing.
2. Pick your algorithms. All four checkboxes can be toggled independently; leave only the ones you need checked to keep the results clean.
3. Click Generate Hashes. Each selected algorithm's digest appears in its own read-only field within a second.
4. Copy what you need. Use the Copy button beside any hash to grab it for a checksum comparison, a commit message, or a test fixture.
5. Compare against a known value. If you're verifying a download or a signature, paste the published hash next to this tool's output and check they match exactly, character for character.

How Hashing Actually Works

A cryptographic hash function takes an input of any length and produces an output of a fixed length — MD5 always outputs 128 bits (32 hex characters), SHA-1 always outputs 160 bits (40 hex characters), SHA-256 outputs 256 bits (64 hex characters), and SHA-512 outputs 512 bits (128 hex characters), regardless of whether your input was one character or one million. Internally, these algorithms process the input in fixed-size blocks through a series of mathematical operations — bitwise shifts, modular additions, logical functions — designed so that the relationship between input and output looks essentially random, a property called the avalanche effect: flip a single bit in the input and roughly half the output bits change. The Web Crypto API's SubtleCrypto.digest() method, which this tool uses for the SHA family, implements these algorithms natively in the browser for speed and correctness; see MDN's SubtleCrypto.digest() documentation for the underlying API.

Hashing Is One-Way — And That's the Whole Point

The property that makes hashing useful is that it's deliberately irreversible. Encryption is two-way by design: you encrypt data with a key, and anyone with the matching key can decrypt it back to the original. Hashing has no key and no decrypt operation — there is no mathematical shortcut that takes a hash and reconstructs the input, short of guessing inputs and hashing each one until you find a match. That's precisely why systems use hashes to store passwords: the server never needs to know your actual password, only a hash of it, so even if the database is stolen, the attacker doesn't get plaintext passwords, just digests they'd have to brute-force one guess at a time. The same one-way property is what makes hashes useful for integrity checks — you can publish the hash of a file publicly without revealing the file's contents, and anyone who downloads the file can hash it themselves and compare.

Why MD5 and SHA-1 Are Considered Broken

MD5 and SHA-1 were the default choices for decades, and you'll still see them everywhere in legacy systems, but both are now cryptographically broken for any purpose involving security. Researchers have demonstrated practical "collision" attacks against both — meaning two different inputs can be crafted to produce the identical hash, which defeats the whole point of using a hash to prove a file or message hasn't been tampered with. MD5 collisions have been achievable on ordinary hardware for years; SHA-1 collisions require more computing power but have been publicly demonstrated as well. Neither algorithm should be used anywhere security matters — not for password storage, not for digital signatures, not for verifying that a downloaded file hasn't been maliciously modified. They remain acceptable for non-security uses like generating a quick checksum to detect accidental corruption, deduplicating files, or building a cache key, where nobody is trying to deliberately forge a collision. For anything with a real security requirement, SHA-256 or SHA-512 is the current baseline, and purpose-built password hashing functions are stronger still, as covered below.

Why Raw SHA-256 Still Isn't Enough for Passwords

Even a strong, uncompromised algorithm like SHA-256 is the wrong tool for hashing passwords directly, because general-purpose cryptographic hashes are built for speed — and speed is exactly what you don't want when an attacker is trying to guess passwords. Modern hardware can compute billions of SHA-256 hashes per second, which means an attacker with a stolen password database can brute-force short or common passwords at enormous scale. Two additional techniques matter here. First, salting: a random, unique value added to each password before hashing, stored alongside the hash, so two users with the identical password get completely different hashes, and precomputed "rainbow table" attacks become useless. Second, purpose-built password hashing algorithms — bcrypt, scrypt, and Argon2 — are deliberately slow and memory-intensive, tunable to stay expensive even as hardware improves, which raises the cost of brute-forcing dramatically compared to a fast general-purpose hash. The SubtleCrypto API documentation on MDN covers what the Web Crypto API can and cannot do here — notably, it doesn't include bcrypt or Argon2 natively, which is why real applications lean on dedicated libraries for password storage rather than hashing passwords with SHA-256 alone.

Practical Uses for This Tool

• Verifying downloads. Compare a file's SHA-256 against the checksum a vendor publishes to confirm the download wasn't corrupted or tampered with.
• Generating cache or dedup keys. Hash a string to get a short, fixed-length, collision-resistant identifier for caching or deduplication logic.
• Testing hashing logic in your own code. Confirm your backend's hash output matches an independently computed reference before shipping.
• Quick data-integrity spot checks. Hash the same text before and after a transfer or transformation to confirm nothing changed.

SHA-256 vs SHA-512: Which One Should You Pick

Both belong to the SHA-2 family and share the same underlying design, but they differ in output size and internal word size — SHA-256 works on 32-bit words and produces a 256-bit digest, while SHA-512 works on 64-bit words and produces a 512-bit digest. In practice, SHA-256 is the more common default: it's what Git uses internally for newer repository formats, what most TLS certificates rely on, and what most checksum tools publish by default, so matching it makes cross-checking easier. SHA-512 offers a larger security margin and, on 64-bit hardware, is sometimes faster than SHA-256 despite producing a longer output, because its internal operations map more naturally onto 64-bit CPU registers. For most day-to-day developer tasks — verifying a download, generating a cache key, checking a config hasn't drifted — either is more than strong enough; pick SHA-256 unless something specific (a spec, a vendor's published checksum format, or an internal standard) calls for SHA-512 instead.

Common Mistakes to Avoid

• Using MD5 or SHA-1 for anything security-related. Both are broken for security purposes; keep them strictly to non-adversarial checksums.
• Hashing passwords with a general-purpose algorithm alone. Use bcrypt, scrypt, or Argon2, with a unique salt per password, in real applications.
• Assuming a matching hash proves two files are identical with 100% certainty. It's astronomically unlikely for SHA-256 or SHA-512 to collide by accident, but it's a probabilistic guarantee, not a mathematical impossibility.
• Comparing hashes visually instead of programmatically. A single mismatched character is easy to miss by eye; copy-paste and compare exactly, or better, compare with code.
• Confusing hashing with encryption. Hashing is one-way and has no decrypt step; if you need to get the original data back, you need encryption, not a hash.

Related Free Tools From Arb Digital

Hashing is often just one step in a bigger encoding or debugging workflow. Try our Base64 Encoder/Decoder for the encoding many hash outputs get wrapped in, the JWT Decoder to inspect tokens that are themselves signed using hashing under the hood, the UUID Generator for generating unique identifiers, and the Password Generator for creating strong passwords in the first place. Browse everything in the free online tools hub.

Frequently Asked Questions