Hash Generator

A hash function takes input of any size and produces a fixed-length fingerprint: change one character of the input and the hash changes completely. The Hash Generator computes the four most-used algorithms instantly and locally: MD5 (128-bit), SHA-1 (160-bit), SHA-256 and SHA-512 — paste text, get hashes, nothing uploaded.

What hashes are for (and the security hierarchy)

Hashes prove two things: integrity (is this file/text exactly what it was?) and identity (are these two things the same?). They’re one-way functions — you can’t reconstruct the input from the hash — which is what makes them fingerprints rather than encodings.

The security hierarchy matters. MD5 and SHA-1 are cryptographically broken — collisions (two different inputs with the same hash) can be constructed in practice. They remain fine for non-adversarial uses — checksums, deduplication, cache keys, change detection — and remain ubiquitous in legacy systems. For anything adversarial — password storage (use dedicated password hashing), certificates, signatures, tamper-proofing — use SHA-256 or SHA-512, full stop.

Where hashes show up in web and SEO work

• Content change detection — hash a page’s content fingerprint to detect exactly when it changed, across crawls.
• Deduplication — hashing titles, descriptions or paragraphs to find exact duplicates across thousands of URLs.
• Cache keys and build integrity — content-addressed assets and file checksums in deployments.
• Subresource integrity (SRI) — the integrity attribute on script/link tags uses SHA-256+ hashes to pin CDN files.

One paste, four algorithms, zero uploads. The workflow is about choosing the right hash for the job and using it consistently.

1. 1
   Open the Hash Generator. Free, instant, private — all hashing runs in your browser.
2. 2
   Paste your input. The text, snippet or content fingerprint you want to hash. The input is never transmitted.
3. 3
   Choose the algorithm. SHA-256 is the sensible default. MD5 only for legacy compatibility or non-adversarial checksums. SHA-512 where longer output is conventional.
4. 4
   Generate the hash. All algorithm outputs appear instantly for comparison.
5. 5
   Copy the hash you need. Into your integrity attribute, change-detection log, deduplication script or verification checklist.
6. 6
   Use it for comparison. Hash the other version of the content — same hash means identical content; any difference means something changed.
7. 7
   Document the algorithm alongside the hash. A hash without its algorithm name is a future debugging mystery. Store “sha256:ab12…” not “ab12…”.

How to interpret the results

A hash is meaningful only in comparison: against a previous hash of the same input (change detection), against a known-good published hash (integrity verification), or against other hashes of other content (deduplication). Two identical inputs always produce identical hashes; even trivially different inputs produce completely different ones — that’s the avalanche property, and it’s why hashing a page’s title is a perfect “did this change” check.

When verifying downloads or CDN files, compare hashes character for character — don’t eyeball. And when a hash “doesn’t match”, check the algorithm first: comparing an MD5 against a SHA-256 is the most common false alarm in verification workflows.

What to do next

Neighbouring utilities: deduplicate lists with Remove Duplicate Lines, verify embedded data with the JSON Formatter, and encode (not hash) transport data with the Base64 Encoder.

Example 1 — the content-change alarm

An agency fingerprints each client page’s main content with SHA-256 during monthly crawls. One month, a homepage’s hash changes though “nobody touched anything” — diffing the versions reveals a tag-manager snippet injected a banner, shifting the content. The hash caught an unannounced change in a 40,000-page estate.

Example 2 — the duplicate-content census

Hashing the meta descriptions of 4,000 product URLs finds 2,200 identical ones — the import template had reused one description across variants. The census takes minutes and quantifies exactly what the duplicate-content cleanup must fix.

Example 3 — the CDN integrity pin

A team loads jQuery from a public CDN with an integrity="sha384-…" attribute — the hash pins the file so a compromised CDN can’t silently swap in malicious code. Generating and verifying that hash is exactly this tool’s job.

Whenever you need a compact, deterministic fingerprint: change detection across crawls, duplicate detection across content sets, integrity verification of files and CDN assets, cache keys, content-addressed naming, and comparing “before and after” states in migrations. In SEO operations specifically, content hashing is the cheapest possible change-detection layer for large sites.

Don’t hash for secrecy (hashes aren’t reversible but weak ones can be brute-forced for short inputs — never “hash” passwords with MD5), and don’t use MD5/SHA-1 where an adversary could benefit from collisions.

• Using MD5 for anything adversarial. Collisions are practical against MD5 and SHA-1. Checksums and dedup, fine; security, never.
• Comparing hashes across algorithms. The number one false mismatch. Always record which algorithm produced a hash.
• Hashing formatted text inconsistently. A trailing newline or whitespace difference changes the hash completely. Normalise input before hashing when you want semantic comparison.
• Hashing passwords at all with these algorithms. Password storage needs slow, salted, purpose-built hashing (bcrypt, Argon2) — not fast general-purpose hashes.
• Forgetting encoding matters. UTF-8 and Latin-1 bytes of the “same” text hash differently. Standardise on UTF-8.

• Default to SHA-256; reserve MD5/SHA-1 for legacy compatibility and non-adversarial checksums.
• Always record the algorithm next to the hash — “sha256:…” not a bare string.
• Normalise input (encoding, whitespace, line endings) before hashing for comparison purposes.
• Use content hashing as your change-detection layer in crawl monitoring.
• For passwords, use purpose-built slow hashing (bcrypt, Argon2) — never these algorithms.

• Text inputs only. This tool hashes pasted text; hashing large binary files is a command-line job.
• No integrity guarantee against adversaries with MD5/SHA-1. Use SHA-256+ wherever an attacker has motive.
• Collision-resistance is probabilistic. Different inputs share hashes extremely rarely by chance — but “rarely” is still the honest word.

• Hashes don’t match but content looks identical. Compare bytes, not appearances: trailing whitespace, line endings and encoding differences all change hashes.
• My verification target lists a different-length hash. Different algorithm. Match the algorithm before assuming a mismatch.
• I need to hash a file, not text. Use a command-line tool (shasum, certutil) or your file manager’s checksum feature for binary files.