About Hash Generator

A cryptographic hash function maps any input to a fixed-size digest: MD5 gives 128 bits (32 hex chars), SHA-1 gives 160, SHA-256 gives 256, SHA-512 gives 512. The same input always produces the same digest; a one-character change produces a completely different one (the avalanche effect); and the function only runs one way — you cannot compute the input from the digest, you can only guess-and-check.

This tool computes MD5, SHA-1, SHA-256, and SHA-512 of your text locally in the browser (SHA variants via the native Web Crypto API). Typical uses: generating checksums, comparing configs without eyeballing them, creating cache keys, and verifying that a file or string matches a published digest.

How to use Hash Generator

  1. Enter or paste the text or data to hash.
  2. Select the hash algorithm (e.g. SHA-256, MD5).
  3. Copy the generated hash from the output.

Example

Input

Your input or data here

Output

Result will appear here after running the tool

Which algorithm should you use in 2026?

SHA-256 is the safe default for integrity: fast, universally supported, no known practical attacks. SHA-512 is comparable security with a larger digest (and is often faster on 64-bit CPUs). SHA-1 is broken for collision resistance — the SHAttered attack (2017) produced two different PDFs with the same SHA-1, and git has been migrating away from it — use it only where a legacy protocol demands it. MD5 collisions can be produced in seconds on a laptop; treat MD5 as a fast checksum for accidental corruption, never as a security control.

A subtle but critical distinction: collision attacks (find any two colliding inputs — broken for MD5/SHA-1) versus preimage attacks (recover an input matching a given digest — still infeasible even for MD5). That is why an MD5 file checksum still detects random corruption fine, but an MD5 signature or certificate is forgeable.

Hashing is not encryption — and plain hashing is not password storage

Encryption is reversible with a key; hashing is not reversible at all. But 'not reversible' does not mean 'safe for passwords': attackers precompute digests of billions of common passwords (rainbow tables) and modern GPUs compute tens of billions of SHA-256 hashes per second. An unsalted fast hash of a human-chosen password falls in minutes.

Password storage needs deliberately slow, salted, memory-hard functions: bcrypt, scrypt, or Argon2id (the current OWASP recommendation). If your use case is 'store user passwords', a general-purpose hash generator — this one included — is the wrong tool, and that is by design.

Text hashing gotchas that cause mismatched digests

  • Trailing newline: echo adds \n, so echo -n "abc" | sha256sum and hashing 'abc' here differ unless you use -n. This bites everyone once.
  • Encoding: hashing operates on bytes. 'é' as UTF-8 (2 bytes) and Latin-1 (1 byte) give different digests. This tool hashes UTF-8.
  • Line endings: the same file with CRLF vs LF produces different digests — a classic Windows-vs-Linux checksum mismatch.
  • Case of the digest: hex digests are case-insensitive by convention (abc123 = ABC123), but string comparison in code is not — normalize before comparing.
  • Invisible characters: a BOM (EF BB BF) or non-breaking space changes the digest while looking identical on screen.

Common errors and how to fix them

My digest doesn't match the published checksum

Cause: Almost always a byte-level difference: trailing newline, CRLF vs LF, BOM, or hashing the text of a file path instead of file contents.

Fix: Hash the exact bytes: use echo -n, check line endings, and confirm you are hashing content, not a filename.

Same text, different hash in another language/tool

Cause: Different input encoding (UTF-8 vs UTF-16LE — PowerShell strings are UTF-16 by default) or one side hex-encodes while the other Base64-encodes the digest.

Fix: Fix encoding to UTF-8 on both sides and compare the raw digest bytes, not their string representations.

I need to 'decrypt' a hash back to the original

Cause: Hashes are one-way; there is nothing to decrypt.

Fix: The only option is guessing: dictionaries and brute force. For your own systems, this is exactly why hashes protect data — design flows so you never need the original back.

Two different inputs must not collide — is MD5 okay?

Cause: MD5 collisions are trivially constructible; an attacker can create two inputs with the same MD5.

Fix: Use SHA-256 anywhere an adversary could choose inputs (signatures, dedup with security implications, content addressing).

Tips and best practices

  • For API request signing, use HMAC (dedicated HMAC Generator tool) rather than hash(secret + message) — length-extension attacks break the naive construction for SHA-256.
  • Digest length identifies the algorithm at a glance: 32 hex chars = MD5, 40 = SHA-1, 64 = SHA-256, 128 = SHA-512.
  • Content addressing (using the digest as an ID, like git or Docker do) needs a collision-resistant hash — SHA-256 today.
  • Comparing two long configs or dumps? Hash both and compare 64 characters instead of scrolling thousands of lines.

Frequently asked questions

Can a hash be reversed?
No — hashing discards information (infinite inputs map to a fixed-size output). The only 'reversal' is guessing inputs and comparing digests, which is why weak passwords behind fast hashes are crackable while the function itself remains one-way.
Is MD5 still usable?
As a quick integrity check against accidental corruption, yes. As a security control (signatures, certificates, dedup where an attacker chooses inputs), no — collisions are constructible in seconds. SHA-256 costs almost nothing more; default to it.
Which hash should I use for storing passwords?
None of these. Use Argon2id, bcrypt, or scrypt — algorithms designed to be slow and memory-hard, with per-password salts. Fast general-purpose hashes (even SHA-512) are crackable at billions of guesses per second on GPUs.
Why does the same word give a different hash than my terminal?
Byte differences: echo appends a newline unless you pass -n, Windows files carry CRLF, PowerShell strings are UTF-16. Identical bytes always produce identical digests — the mismatch is in the bytes, not the algorithm.
What's the difference between SHA-256 and SHA-512?
Digest size (256 vs 512 bits) and internals (32- vs 64-bit words; SHA-512 is often faster on 64-bit CPUs). Both are current-generation secure. SHA-256 is the interoperability default; SHA-512 where you want extra margin or hash very large volumes on modern hardware.
Is my input sent anywhere?
No — hashing runs locally (Web Crypto API for the SHA family). Nothing leaves your browser.

Embed this tool

Add Hash Generator to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.

Related tools