Free hash generator — MD5, SHA-256, SHA-512, SHA-3, BLAKE2 and more. Hash text or files in your browser.

Six dimensions of configurability — each with sensible defaults. The most-used setup (SHA-256 in HEX, no HMAC, no salt) takes zero configuration; the advanced options are there for the cases that need them.

Hashes show up everywhere in modern software because they solve a specific cluster of problems: producing a small, fixed-size, content-addressable identifier from arbitrary data. Five recurring needs they cover well:

• File integrity verification Download checksums (SHA-256SUMS files), software-distribution signatures, backup integrity checks, deduplication. Same input → same hash, always. Changed input → completely different hash. The original use case and still the most common.
• Cache and dedupe keys A short, fixed-size key that identifies a piece of content. CDN cache keys, Redis keys for content-addressable storage, S3 etag-style identifiers, deduplication in backup systems. SHA-256 is overkill for this — MD5 is fine when collision resistance under attack doesn't matter.
• Message authentication (HMAC) API request signing (AWS SigV4, Stripe webhooks, Slack signing secrets), JWT signatures with shared-secret algorithms (HS256/384/512). Hashing alone proves integrity; HMAC adds authenticity — proving both that the message wasn't modified AND that it came from someone who knows the key.
• Content addressing Git uses SHA-1 (migrating to SHA-256) to identify every commit, tree, and blob. IPFS uses multihash. Blockchain transactions use SHA-256 (twice, for Bitcoin) or Keccak-256 (for Ethereum). When the hash IS the identity, you don't need a separate database key.
• Cryptographic primitive in larger protocols TLS handshakes, digital signatures, X.509 certificates, key derivation functions (HKDF, PBKDF2). You rarely use a raw hash here directly — it's a building block other constructs are built on top of.

A cryptographic hash function takes input of any size and produces a fixed-size output. The pipeline is short — the interesting choices are in which algorithm, which output format, and whether to add HMAC or salt.

• Stage 1 — Read input Paste/type → string. Upload → file stream. Files larger than a few MB are processed chunk-by-chunk so memory stays bounded regardless of file size.
• Stage 2 — Apply salt (if enabled) Prepend the salt bytes to the input before hashing. Salt is treated as a string by default; for binary salts, encode as hex first.
• Stage 3 — Apply the algorithm The Web Crypto API runs the actual hash function (or BLAKE2 / SHA-3 via a small WebAssembly polyfill for algorithms the browser doesn't expose natively). One-way, deterministic, avalanche — same input always produces the same output; any change to input produces a totally different output.
• Stage 4 — Apply HMAC (if enabled) If an HMAC key is provided, the algorithm runs in HMAC mode (RFC 2104) instead of plain hash mode. Uses inner and outer padded keys to prevent length-extension attacks — much stronger than naive `hash(key || message)` construction.
• Stage 5 — Encode output The raw bytes from the hash function get encoded as HEX, BASE64, or returned as raw BINARY. The encoding doesn't change the cryptographic strength — it's purely a display/transmission choice.

Eleven algorithms supported. Each was designed for a specific era and use case, with different security properties, output sizes, and performance characteristics. The short version: pick SHA-256 unless you have a specific reason to choose something else.

• MD5 (1991) — 128-bit — broken Designed by Ron Rivest at MIT. Once the standard cryptographic hash; broken since the early 2000s. Collisions (two different inputs producing the same hash) can be generated in seconds on a laptop. Still safe for non-security uses — detecting accidental file corruption, generating cache keys, deduplication. Never use for password storage, digital signatures, or anything where an attacker can control the input.
• SHA-1 (1995) — 160-bit — broken in 2017 Designed by the NSA. Replaced MD5 for security uses, then was itself broken in 2017 — Google's 'SHAttered' attack demonstrated a practical collision. Major browsers phased out SHA-1 TLS certificates by 2017. Still in active use in Git (migrating to SHA-256), in HMAC-SHA1 contexts (where collision resistance isn't required), and in legacy systems that can't easily migrate.
• SHA-256 (2001) — 256-bit — current default Part of the SHA-2 family. The default cryptographic hash for almost every modern application — TLS certificates, Bitcoin block hashes, JWT signing, Git's new format, software-distribution integrity, content-addressed storage. No practical attacks known. If you don't know which hash to pick, pick this one.
• SHA-512 (2001) — 512-bit Sibling of SHA-256 in the SHA-2 family. Runs ~50% faster than SHA-256 on 64-bit platforms (uses 64-bit internal operations); slower on 32-bit and embedded. Same security level as SHA-256 against current attacks. The longer output is useful if you need more bits — e.g., for key derivation, custom truncation, or wider HMAC keys.

• SHA3-256 (2015) — sponge construction — recommended Winner of NIST's hash competition (2007–2012). Internally totally different from SHA-2 — uses 'sponge construction' from the Keccak algorithm. Designed as an algorithmic hedge in case SHA-2 is ever broken. Slower than SHA-2 in software, faster in hardware. Use when you need NIST FIPS-202 compliance or want algorithmic diversity.
• SHA3-512 — wider output Same sponge construction as SHA3-256, larger output. Useful when you specifically need a 512-bit hash and want the SHA-3 family rather than SHA-512.
• SHA3-224 and SHA3-384 — truncated variants Same family, different output lengths. Used in protocols that specify exact hash widths (some signature schemes, some HSM configurations). Rare outside of standards-driven contexts.

• BLAKE2B (2012) — fast, modern, up to 512-bit Designed by Aumasson, Neves, Wilcox-O'Hearn, and Winnerlein. Significantly faster than SHA-2 and SHA-3 in software with the same security level. Used inside WireGuard, Argon2, and many newer protocols. Optimized for 64-bit CPUs. The right pick when you need both speed and modern security.
• BLAKE2S — 32-bit variant Same design as BLAKE2B, optimized for 32-bit platforms (older mobile, embedded systems, IoT, constrained devices). Smaller internal state, output up to 256 bits. Used in cryptocurrency wallets and embedded contexts where memory matters.
• RIPEMD-160 (1996) — 160-bit — legacy Designed in Europe as an open-academic alternative to NSA-designed algorithms. Best known today for Bitcoin's address derivation (the network combines SHA-256 and RIPEMD-160 for address hashes). Otherwise rarely used. No known practical attacks but considered legacy — not a recommended choice for new applications.

Hashes are binary blobs. To display, transmit, or store them, you need an encoding. Three common ones — each useful in different contexts. None of them changes the cryptographic strength of the hash; they're purely about display:

• HEX — case-insensitive, universally readable Each byte becomes two hex characters (0–9, a–f). MD5 = 32 chars, SHA-1 = 40 chars, SHA-256 = 64 chars, SHA-512 = 128 chars. ASCII-safe, easy to copy/paste, easy to compare visually (humans can usually spot a one-character difference). The default for almost every developer tool, including the SHA-256SUMS files distributed alongside software downloads.
• BASE64 — compact and URL-safe Each 3 bytes becomes 4 ASCII characters. About 33% more compact than HEX. Used in HTTP headers (Content-MD5), JWT signatures, base64-encoded API tokens, and anywhere bandwidth matters. The URL-safe variant uses `-` and `_` instead of `+` and `/` so the value can be put directly in a URL. Slightly harder to compare visually than HEX.
• BINARY — raw bytes The unmodified output of the hash function. Half the size of HEX. Use when storing in BLOB database columns, transmitting over binary protocols, or piping into other binary tools. Cannot be safely displayed as text — most bytes don't correspond to printable characters.

Two extensions of basic hashing, often confused. They solve different problems. Neither one, alone or combined, makes general-purpose hashing safe for password storage — see section 07.

• HMAC — what it is Hash-based Message Authentication Code (RFC 2104). Combines a hash function with a secret key. The output looks like a normal hash but can only be reproduced by someone who knows the key.
• HMAC — what it solves Plain hashing proves integrity — anyone can recompute the hash to check if data was tampered with. HMAC additionally proves authenticity — only someone with the key can produce a valid HMAC. This is what you actually want for API request signing, JWT, webhook verification, and any 'prove this came from us' use case.
• HMAC — when to use it AWS Signature V4 (HMAC-SHA256), Stripe webhook signatures (HMAC-SHA256), Slack request signing (HMAC-SHA256), JWT with HS256/HS384/HS512, basically every shared-secret authentication scheme in modern web protocols.
• HMAC — the common mistake Don't roll your own with naive `hash(key + message)` or `hash(message + key)` — both have known weaknesses (length-extension attacks against MD5/SHA-1/SHA-2 chains). Real HMAC uses inner-padded and outer-padded keys precisely to prevent these. Always use the HMAC mode of your crypto library, not a hand-rolled construction.

• Salt — what it is A value (usually random) added to the input before hashing. Same input + different salts = different hashes.
• Salt — what it solves (in this tool) Useful for making the same input produce different hashes — cache key uniqueness across tenants, dedupe tokens that shouldn't collide across users, generating distinct identifiers for the same content in different contexts.
• Salt — what it does NOT solve Salt does NOT make a general-purpose hash safe for password storage. SHA-256(password + salt) computed on a GPU farm can try billions of password candidates per second per device. Salt only defeats rainbow tables; it doesn't slow down brute force. Real password hashing requires deliberately slow, memory-hard algorithms — bcrypt, scrypt, or Argon2id. Section 07 has the details.

Cryptographic hashes aren't the right tool for every problem. Three things they get commonly misused for — each of which has real, well-established alternatives:

• Password storage → use bcrypt, scrypt, or Argon2id General-purpose hashes (including SHA-256 with salt) are fast — that's exactly the wrong property for password hashing. Modern GPU farms can compute billions of SHA-256 hashes per second, making brute-force attacks against leaked password databases practical. Password hashes need to be deliberately slow and memory-hard. Use Argon2id (current best, OWASP recommendation), or bcrypt (older but still acceptable, widely supported). Most languages have a built-in or well-maintained library — `bcryptjs` / `@node-rs/argon2` in Node, `passlib` / `argon2-cffi` in Python, `BCrypt.Net-Next` in .NET. This tool deliberately doesn't implement password hashing — using the wrong primitive is exactly how `LinkedIn 2012` happens.
• Encryption → use AES-GCM or ChaCha20-Poly1305 Hashes are one-way. You can produce a hash from data, but you can't get the data back from a hash — that's the point. If you need to encrypt something you'll later decrypt, you need an encryption algorithm, not a hash. AES-GCM (the standard) or ChaCha20-Poly1305 (modern alternative) are both well-supported across languages.
• Random number generation → use a CSPRNG Don't hash a timestamp or session ID and call it 'random'. Use your platform's cryptographically secure random number generator — `crypto.getRandomValues()` in browsers, `crypto.randomBytes()` in Node, `secrets` module in Python, `/dev/urandom` on Unix. These are designed for the job; hashing of insufficient-entropy inputs isn't.

For programmatic hashing — for example as part of a build pipeline, file-integrity checker, or webhook signature verifier — the same functionality is exposed via JSON API. For browser-side use, prefer the Web Crypto API directly (it's the same primitives, with no network round-trip).

const res = await fetch('https://api.domainscan.in/v1/hash', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    input:        'hello world',
    algorithm:    'sha256',
    outputFormat: 'hex'
  })
});
const data = await res.json();
console.log(data.hash);
// 'b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9'

// With HMAC
const signed = await fetch('https://api.domainscan.in/v1/hash', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    input:        'payload to sign',
    algorithm:    'sha256',
    outputFormat: 'base64',
    hmac:         'my-secret-key'
  })
}).then(r => r.json());

console.log(signed.hash); // HMAC-SHA256 in base64

// For local-only / privacy-sensitive use, the Web Crypto API is the right choice —
// no network call, no data leaves the browser:
const enc = new TextEncoder();
const buf = await crypto.subtle.digest('SHA-256', enc.encode('hello world'));
const hex = [...new Uint8Array(buf)].map(b => b.toString(16).padStart(2, '0')).join('');
console.log(hex);

{
  "success":      "boolean",
  "hash":         "string (the hash in the requested output format)",
  "algorithm":    "md5 | sha1 | sha256 | sha512 | sha3-224 | sha3-256 | sha3-384 | sha3-512 | blake2b | blake2s | ripemd160",
  "outputFormat": "hex | base64 | binary",
  "salt":         "string | null (echoed back if provided)",
  "hmac":         "string | null (HMAC key, echoed back if provided)",
  "time":         "number (computation time in ms)"
}

// Request body
{
  "input":        "string (required — the data to hash)",
  "algorithm":    "string (required — see options above)",
  "outputFormat": "string (optional — defaults to hex)",
  "salt":         "string (optional — prepended to input before hashing)",
  "hmac":         "string (optional — if provided, runs in HMAC mode with this as the key)"
}

Six patterns we see most often:

• What's the difference between MD5 and SHA-256? MD5 is a 128-bit hash from 1991, broken since the early 2000s — collisions can be generated in seconds. SHA-256 is a 256-bit hash from 2001, with no known practical attacks. For non-security uses (file integrity checks, cache keys, deduplication), MD5 is still acceptable and slightly faster. For anything where an attacker controlling the input matters, SHA-256 is the right choice. If you're not sure, pick SHA-256.
• Is MD5 still safe to use? For non-security uses, yes. Detecting accidental file corruption, generating cache keys, deduplication — MD5 is fine and arguably faster than alternatives. The brokenness only matters when an attacker can choose the input and benefit from finding two inputs that hash the same. For password storage, signing, certificate fingerprints, anywhere an adversary controls inputs — never use MD5.
• What hash should I use for storing passwords? None of these. Use Argon2id (current OWASP recommendation), scrypt, or bcrypt — typically via your language's well-maintained library: `@node-rs/argon2` in Node, `argon2-cffi` in Python, `BCrypt.Net-Next` in .NET. These are deliberately slow and memory-hard, which is exactly the wrong property for general-purpose hashing but exactly the right property for password storage. This tool deliberately doesn't implement password-hashing functions because doing it safely requires more than just picking an algorithm.
• What's the difference between HEX, BASE64, and BINARY output? They're all the same hash, encoded differently. HEX uses two hex characters per byte (so a SHA-256 hash is 64 chars). BASE64 uses ASCII characters and is about 33% more compact. BINARY is the raw bytes. None of them is cryptographically stronger than the others — pick based on where you'll display, store, or transmit the result.
• What is HMAC and when should I use it? HMAC is keyed hashing. Where a plain hash proves only integrity ('this data wasn't modified'), HMAC additionally proves authenticity ('this came from someone who knows the key'). Use HMAC for API request signing, JWT (when using HS256/384/512), webhook signature verification, and any case where a server needs to verify both that a message is intact AND that it came from an authorized source.
• Why is my hash different from another tool's hash? Three usual culprits. (1) Different input encoding — UTF-8 vs UTF-16, or a trailing newline that one tool includes and another doesn't. (2) Line endings — Windows CRLF vs Unix LF, which change the byte content of text. (3) Different output format — comparing HEX to BASE64 or vice versa. Hash the exact same bytes in the same encoding and you'll get the same hash, every time. If you don't, one of these three things is different.
• Can I hash files in this tool? Yes — click 'Upload File'. Files are processed in chunks via the browser's streaming APIs, so a 1 GB file doesn't load entirely into memory. The hash is computed entirely in your browser; the file is never sent to our servers. The same applies to text input.
• Is my data sent to your servers? Not for the UI. The tool uses the browser's Web Crypto API and runs all hashing locally — input text, file contents, HMAC keys, and salts never leave your device. The history panel writes to your browser's local storage only. The API endpoint exists for programmatic use cases that need a server-side hash (build pipelines, etc.), but the website UI doesn't depend on it. Open DevTools while you hash something to verify: no outgoing requests.