Multi-algorithm hashing + verify mode with auto-detection

Verifying integrity is more common than people realise

Hash generation shows up in surprising places: cache keys, content-addressed storage, file-download verification, idempotency tokens for safe retries, deduplication. The hash itself is straightforward — every modern runtime ships SHA-256 in its standard library. The shape of the question is what varies: sometimes you need every algorithm in parallel (download integrity verification across providers that publish different hash algorithms), sometimes you need to verify an unknown hash against a known input (which algorithm produced this hash?), sometimes you need to detect collisions across a corpus.

Generic CLI tools (sha256sum, md5sum) handle one algorithm at a time and don't help with verification or auto-detection.

Why multi-algorithm + verify mode

The tool in this article produces hashes across all common algorithms in one call (MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA-3 variants, BLAKE2b, BLAKE3) — useful when a provider publishes only one and the consumer needs another, or when you're producing a content-addressed-storage key and want every variant available for the lookup table.

Verify mode accepts a known hash and an input; the tool detects the algorithm from the hash length, recomputes against the input, and reports whether they match. The auto-detection (32 hex chars → MD5, 64 → SHA-256, 128 → SHA-512) removes the "which algorithm produced this hash?" question that breaks every download-verification workflow when the provider changes algorithms.

What this article delivers

Multi-algorithm generation walked against a single input, verify mode against an unknown hash, and the cases where multiple algorithms have the same hash length (SHA-256 and BLAKE2b-256 both produce 64 hex chars — auto-detection picks the more common one and surfaces a warning).

By the end of this article you will be able to:

• Generate hashes across MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA-3 variants, BLAKE2b, and BLAKE3 from one input in a single call
• Verify any known hash against an input — the tool auto-detects the algorithm from the hash length
• Choose between hex and base64 output encoding based on the consumer's expectation
• Recognise the cases where auto-detection is ambiguous (multiple algorithms producing the same hash length) and pass verifyAlgorithm explicitly
• Pick the right algorithm for the use case — fast non-cryptographic vs cryptographic vs password hashing (which this tool intentionally doesn't cover)

The Examples section walks through multi-algorithm generation, verify mode with auto-detection, and the explicit-algorithm fallback.

Before / after: every algorithm in one call

hashGenerator({
  input: 'Hello, world!',
  mode:  'generate',
});

// hashes: {
//   md5:        '6cd3556deb0da54bca060b4c39479839',
//   sha1:       '943a702d06f34599aee1f8da8ef9f7296031d699',
//   sha256:     '315f5bdb76d078c43b8ac0064e4a0164612b1fce77c869345bfc94c75894edd3',
//   sha384:     '...',
//   sha512:     '...',
//   'sha3-256': '...',
//   'sha3-512': '...',
//   blake2b:    '...',
//   blake3:     '...',
// }
// meta: { inputBytes: 13, inputEncoding: 'utf-8', computeMs: 2 }

Every common algorithm from one input. Useful when a provider publishes only SHA-256 and your consumer expects BLAKE3, or when you're building a content-addressed-storage scheme and want every variant available.

Before / after: verify with auto-detect

You have a hash from a download page and you want to verify a downloaded file:

hashGenerator({
  input:      fileBuffer.toString('utf-8'),
  mode:       'verify',
  verifyHash: '315f5bdb76d078c43b8ac0064e4a0164612b1fce77c869345bfc94c75894edd3',
});

// verified: {
//   match:             true,
//   detectedAlgorithm: 'sha256',  // detected from 64 hex chars
//   inputHash:         '315f5bdb76d078c43b8ac0064e4a0164612b1fce77c869345bfc94c75894edd3',
// }

The tool detected sha256 from the 64-character hex hash length, computed sha256 against the input, and reported match: true. No "what algorithm is this?" lookup required.

Before / after: ambiguous hash length

64 hex chars could be SHA-256 or BLAKE2b-256. The tool picks SHA-256 (more common) and surfaces the ambiguity as a warning:

hashGenerator({
  input:      data,
  mode:       'verify',
  verifyHash: '<64 hex chars>',
});

// verified: { match: ..., detectedAlgorithm: 'sha256' }
// warnings: ['Hash length 64 hex chars is ambiguous between SHA-256 and BLAKE2b-256. Defaulted to SHA-256. Pass verifyAlgorithm explicitly if BLAKE2b was intended.']

For the BLAKE2b case, pass verifyAlgorithm explicitly:

hashGenerator({
  input:           data,
  mode:            'verify',
  verifyHash:      '<64 hex chars>',
  verifyAlgorithm: 'blake2b',
});

// verified: { match: ..., detectedAlgorithm: 'blake2b' }

Before / after: hex vs base64 output

hashGenerator({
  input:    'data',
  mode:     'generate',
  algorithms: ['sha256'],
  encoding: 'hex',
});

// hashes: { sha256: '3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7' }

hashGenerator({
  input:    'data',
  mode:     'generate',
  algorithms: ['sha256'],
  encoding: 'base64',
});

// hashes: { sha256: 'OmsweA85rIfJTzhWst0sXREOaBFgIhqamS07I63Iy7c=' }

Hex is more common in download-verification contexts; base64 is more common in JWT and OAuth contexts (signature segments are base64url-encoded). Same hash, different encoding.

When humans use this

Developers building cache keys or content-addressed-storage identifiers use multi-algorithm mode to produce a deterministic short identifier from input data. Anyone verifying a downloaded file against a published hash uses verify mode with auto-detection — the algorithm is implicit in the hash length most of the time. Security incident responders use verify mode to confirm whether a captured file matches a published indicator-of-compromise hash.

When agents use this

Two patterns:

• Content-addressed deduplication. An agent processing a corpus of inputs generates a hash per input, dedupes against a hash registry, and processes only new content. The choice of algorithm (BLAKE3 for speed, SHA-256 for ecosystem compatibility) is per-pipeline.
• Idempotency-token generation. An agent producing idempotency keys for mutating HTTP calls hashes a canonical representation of the request payload. Same payload + same algorithm always produces the same key — safe to retry on transient failures.

Edge cases

Don't use for password storage

This tool produces fast hashes for integrity and identity. Password storage needs slow hashes — bcrypt, scrypt, or argon2 — calibrated to take 100-500ms per hash to defeat brute-force attempts. Fast hashes (SHA-256, BLAKE3) compute millions per second on a GPU and let an attacker brute-force a leaked password database in days.

MD5 and SHA-1 are still useful

Cryptographically broken (collisions can be produced); structurally fine for non-security uses (cache keys, integrity check on trusted-source files, content-addressed-storage where collision attacks aren't in the threat model). The tool ships them because legacy systems still use them — verify mode against an MD5 from a 2015 release file is a real use case.

Empty input

hashGenerator({ input: '' }) produces hashes of the empty string. Every algorithm has a documented hash for empty input (MD5: d41d8cd98f00b204e9800998ecf8427e, SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855) — useful for sentinel values but rarely the goal.

Large inputs

The tool handles inputs up to 50MB. Above that, streaming hash computation is the right tool — the SDK in your runtime can hash a file via a stream without loading the whole thing into memory.

Input parameters

Output shape

{
  hashes?: Record<string, string>;    // generate mode
  verified?: {                         // verify mode
    match:             boolean;
    detectedAlgorithm: string;
    providedAlgorithm?: string;        // when verifyAlgorithm was set
    inputHash:         string;         // hash of the input for comparison
  };
  meta: {
    inputBytes:    number;
    inputEncoding: string;
    computeMs:     number;             // wall-clock time for all algorithms
  };
  warnings: string[];
}

Algorithm reference

Auto-detection from hash length

SHA-256 vs SHA-3 vs BLAKE3: which cryptographic hash

The three modern cryptographic hash families differ in security construction, raw speed, and hardware acceleration availability. Picking one wrong won't break your security model but can leave significant performance on the table.

Use SHA-256 when interoperability matters more than peak speed. It's the default for TLS certificate fingerprints, JWT signatures, Git commit hashes, Bitcoin, and every "hash" field in every common spec. With SHA-NI hardware acceleration (Intel ≥ Goldmont, AMD ≥ Zen, ARMv8) the speed gap to BLAKE3 nearly closes on small inputs.

Use SHA-3 when you need length-extension resistance without HMAC (rare — most protocols use HMAC anyway) or your security policy mandates SHA-3 specifically. Some government and banking environments require post-2015 algorithms as defense-in-depth against undiscovered SHA-2 weaknesses. SHA-3 is the slowest choice on every common CPU — pick it deliberately, not by default.

Use BLAKE3 when you control both sides of the wire and want maximum throughput. It dominates for:

• Content-addressed storage (bao, IPFS variants)
• Large-file deduplication (dedup speed = hash speed)
• High-volume cache key generation
• Anywhere sha256sum on a multi-GB file feels slow

Don't use MD5 or SHA-1 for any security-relevant application — both have practical collision attacks. They remain useful only as content fingerprints in trusted environments where collision resistance isn't the property you need: cache keys, ETags, non-security CRC-equivalents. Git still uses SHA-1, but with collision-detecting variants and migration to SHA-256 underway.

For password hashing, none of these are correct. Plain cryptographic hashes are deliberately fast — exactly the wrong property for password storage. Use bcrypt, scrypt, or Argon2id (see the password entropy article for the comparison).

Error codes

When NOT to use this tool

For password hashing, use bcrypt, scrypt, or argon2 with appropriate cost parameters. Fast cryptographic hashes are the wrong primitive for storing passwords — see password_entropy tool for password-policy guidance.

For HMAC (keyed-hash for authentication), use hmac_gen — it handles the key derivation and timing-safe comparison this tool doesn't.

For real-time streaming hashes of very large inputs (multi-GB files), use the runtime's streaming hash API. This tool loads the full input into memory.

Performance notes

Typical execution: under 5ms for all 9 algorithms against inputs under 100KB. BLAKE3 is the fastest; MD5 is the second-fastest (despite being older). Deterministic — same input always produces the same hashes, REST responses are Edge-Cache eligible.