b2KIT

Hash Speed Comparison Benchmark

Benchmark hash functions (MD5, SHA-1, SHA-256, SHA-3, BLAKE3) in your browser and compare throughput in real time.

Tested tool guide Tested browser tools Checked August 16, 2026

What Hash Speed Comparison Benchmark does and how it behaves

Hash functions differ sharply in speed, and this tool measures the gap. It hashes an in-memory buffer repeatedly, times the work, and reports throughput for MD5, SHA-1, SHA-256, SHA-3, and BLAKE3 side by side, in megabytes per second. Browsers natively expose only SHA-1 and the SHA-2 family, so MD5, SHA-3, and BLAKE3 must run as JavaScript, meaning the five algorithms are not competing on equal footing. The thing users most often get wrong: the results describe this browser on this machine at this moment, not your server, and BLAKE3 does not always beat SHA-256.

How the result is produced

1

What is being measured

Throughput, not latency: total bytes hashed divided by elapsed wall-clock time, reported in megabytes or gigabytes per second. The benchmark hashes the same data buffer many times and divides by the clock, so the figure is an average, not a single-run number. Buffer size drives the result - small buffers stay resident in the CPU cache and look unrealistically fast, while large buffers eventually hit memory bandwidth.

2

Why results drift between runs

SHA-1 and SHA-256 take the browser's native code path, which some CPUs accelerate with dedicated instructions; MD5, SHA-3, and BLAKE3 are JavaScript, so their speed depends on the engine - V8, SpiderMonkey, or JavaScriptCore - and on just-in-time warm-up. Background tabs, power management, and other processes add noise. Relative order can flip between browsers, which is the main reason to benchmark locally rather than trust published tables.

Good uses

  • Choosing between BLAKE3 and SHA-256 for a client-side integrity check, deduplication, or content-addressing feature, measured in the browsers your users actually run rather than a blog post's benchmark.
  • Confirming that hashing large files in the browser - upload deduplication, checksum verification - stays fast enough to keep the page responsive on typical consumer hardware.
  • Demonstrating that legacy MD5 and SHA-1 being fast is not a reason to keep them: the tool makes the speed gap visible, which is often exactly what a migration conversation needs.

Limits and checks

  • Numbers are this browser, this machine, this moment. They do not predict your server's OpenSSL, another browser, or another OS, so do not copy the ranking into documentation as a portable fact.
  • Throughput tracks the buffer size you select. Small buffers are cache-warm and flatter unrealistically high numbers; large buffers eventually hit memory bandwidth, at which point the memory subsystem - not the hash - is the bottleneck.
  • The native and JavaScript lanes are not measured on equal footing, and a fast MD5 or SHA-1 says nothing about security: both have practical collision attacks.

Common questions

Is BLAKE3 always the fastest in this benchmark?

No. BLAKE3 runs as JavaScript because browsers do not ship it natively, while SHA-256 uses the browser's native path, which some CPUs accelerate in hardware. On such machines SHA-256 often leads; on others, or in engines with a fast compiler, BLAKE3 wins. There is no universal ranking, which is precisely why you should benchmark on the machines you care about.

MD5 tops the chart. Can I keep using it?

Not for anything adversarial. MD5 and SHA-1 both have practical collision attacks; a benchmark measures throughput, not security. They remain defensible only as checksums against accidental corruption or for deduplicating non-hostile data. A fast result is an argument for migrating off them, not for staying.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools