MD5 vs SHA-256 Speed: SHA-256 Was 3.4x Faster on M4

The usual answer is that MD5 is faster than SHA-256. On the Mac mini M4 that runs this blog, it was the other way round. openssl speed with OpenSSL 3.6.4 hashed 16 KB blocks at 3,356 MB/s with SHA-256 and 979 MB/s with MD5, so SHA-256 was 3.4 times faster. Python's hashlib gave almost the same split on a 1 GiB buffer: 3,397 MB/s against 974 MB/s.

The reason is hardware. The M4 has CPU instructions for SHA-1, SHA-256, SHA-512 and SHA-3, and none for MD5. But the bigger surprise came from the command-line tools. The shasum -a 256 that ships with macOS ran at 595 MB/s, which is slower than every MD5 tool I tried. So if checksumming feels slow on a Mac, look at which program you're running before you look at the algorithm.

The old answer came from x86

A Security Stack Exchange question, which hash algorithm takes longer, MD5 or SHA-256 (19,579 views when I checked through the API tonight), has a top answer with an openssl speed table. In it, 8 KB blocks hashed at 580 MB/s with MD5 and 237 MB/s with SHA-256. MD5 was 2.4 times faster. The same answer says modern CPUs have hash acceleration and results depend on hardware. That's the part that matters now.

Even then, the folk rule had exceptions. A 2020 Stack Overflow question asked why MD5 took 5.89 seconds and SHA-256 2.97 seconds for a million short strings in C#. Its only answer says MD5 is "generally faster" but hardware acceleration and implementation can flip it. On Apple silicon the flip is the normal case.

openssl speed: SHA-256 wins at 16 bytes and up

I ran openssl speed md5 sha1 sha256 sha512 with both copies of OpenSSL on this machine: the LibreSSL 3.3.6 that macOS puts at /usr/bin/openssl, and Homebrew's OpenSSL 3.6.4. Numbers are MB/s (OpenSSL prints thousands of bytes per second).

Block size	MD5, OpenSSL 3.6.4	SHA-256, OpenSSL 3.6.4	MD5, LibreSSL 3.3.6	SHA-256, LibreSSL 3.3.6
16 bytes	149	228	166	120
64 bytes	386	844	402	386
256 bytes	717	1,943	698	1,260
1 KB	899	2,851	854	2,405
8 KB	972	3,315	914	3,232
16 KB	979	3,356	n/a	n/a

With OpenSSL 3.6.4, SHA-256 beat MD5 at every size, including 16-byte inputs. LibreSSL is the one place MD5 still won: at 16 bytes, 166 against 120 MB/s, and roughly a tie at 64. LibreSSL's speed stops at 8 KB. At file-sized blocks both libraries put SHA-256 at more than three times MD5.

Why: the instructions are there for SHA, not MD5

macOS reports CPU features through sysctl, and Apple documents the hw.optional.arm.FEAT_* names in Determining instruction set characteristics. On this M4:

$ sysctl hw.optional.arm.FEAT_SHA1 hw.optional.arm.FEAT_SHA256 \
         hw.optional.arm.FEAT_SHA512 hw.optional.arm.FEAT_SHA3
hw.optional.arm.FEAT_SHA1: 1
hw.optional.arm.FEAT_SHA256: 1
hw.optional.arm.FEAT_SHA512: 1
hw.optional.arm.FEAT_SHA3: 1

There is no MD5 entry because no ARM extension accelerates MD5. MD5 runs as plain integer code, and each step depends on the one before, so a faster core can only do so much. That's why every MD5 result on large inputs in this post sits between about 820 and 980 MB/s, no matter which program ran it.

The instructions only help if the library uses them, and here the two OpenSSLs split. LibreSSL 3.3.6 hashed SHA-256 at 3,232 MB/s but SHA-1 at 1,292 and SHA-512 at 973. OpenSSL 3.6.4 did SHA-1 at 3,355 and SHA-512 at 1,882. So the macOS-bundled library accelerates SHA-256 and apparently not the other two. One more result that runs against older advice: SHA-512 was slower than SHA-256 on both. The tip that SHA-512 is faster on 64-bit CPUs comes from software implementations, where SHA-512 does more work per round on 64-bit words.

The tool matters more than the algorithm

Benchmarks of a library don't tell you what shasum does. So I made a 1 GiB file of random bytes, read it once to warm the cache, and hashed it three times with every command-line tool on the machine. Tools for the same algorithm all printed the same digest.

Tool	What it is	SHA-256	SHA-1	SHA-512	MD5
openssl dgst (OpenSSL 3.6.4)	Homebrew	0.42 s	0.42 s	0.67 s	1.20 s
openssl dgst (LibreSSL 3.3.6)	/usr/bin, built in	0.42 s	0.92 s	1.19 s	1.27 s
/sbin/sha256sum, /sbin/md5	built in since macOS 15, links libmd	0.45 s	0.46 s	0.69 s	1.31 s
shasum	/usr/bin, a Perl script	1.80 s	1.03 s	1.67 s	n/a
gsha256sum, gmd5sum	Homebrew coreutils 9.12	1.87 s	0.91 s	1.22 s	1.23 s

shasum took 1.80 seconds where /sbin/sha256sum took 0.45, four times as long, and it was slower than /sbin/md5 on the same file. /usr/bin/shasum is a Perl script that calls the Digest::SHA module (version 6.02 here). Its C code is portable and doesn't use the SHA instructions, so it gets about what software SHA-256 can do on one core.

GNU coreutils from Homebrew landed in the same place, 574 MB/s for gsha256sum. coreutils can hand hashing to OpenSSL's libcrypto when it's built that way, but Homebrew's coreutils formula doesn't pass an OpenSSL option, and otool -L /opt/homebrew/bin/gsha256sum lists only libSystem. So the GNU tools use their own portable code. If you installed coreutils to get sha256sum on an older Mac, it works, but it isn't fast. I covered the built-in sha256sum and its -c quirk in sha256sum on Mac.

The slowest tool of all was cksum, 561 MB/s. It computes the POSIX CRC, which people reach for because they assume a checksum is cheaper than a hash. On this Mac, SHA-256 through openssl was 4.5 times faster. GNU's gcksum -a crc32b took 0.46 seconds on the same file, so a fast CRC is possible; the macOS cksum just isn't one.

Many small files: start-up cost, then batching

For one big file, throughput is what you feel. For thousands of small files, the cost of starting the program can be bigger than the hashing. I timed one process per file on 50 files of 4 KB, then one call with 2,000 files as arguments.

tool               one process per file   2,000 files, one call
shasum -a 256          7.9 ms                0.061 s
/sbin/sha256sum        1.4 ms                0.047 s
/sbin/md5              1.5 ms                0.054 s
gsha256sum             1.7 ms                0.051 s
openssl (LibreSSL)     1.6 ms                0.033 s
openssl (3.6.4)        3.4 ms                0.029 s

Starting Perl costs shasum about 6 ms more per run. Over 2,000 files that is 16 seconds if a script loops and calls it once per file, against 0.06 seconds for one call with every file as an argument. Pass files in batches, for example with find … -print0 | xargs -0 sha256sum, and the per-process cost goes away.

Several big files: run them side by side

Every tool here hashes a file on one core. The M4 has 10. With four 1 GiB files in cache, one call to /sbin/sha256sum took 1.77 seconds. Four processes at once took 0.52. shasum -a 256 went from 7.25 to 2.05 seconds and /sbin/md5 from 5.25 to 1.50. With xargs -P, that's one flag:

find ~/Downloads/isos -type f -print0 | xargs -0 -n 1 -P 4 sha256sum

Output order follows whichever process finishes first, so sort the result if you compare it with a saved list.

Python hashlib

Python asks the same question often enough to show up in search suggestions. On a 1 GiB in-memory buffer, Homebrew's Python 3.14.7 (built on OpenSSL 3.6.4) hashed SHA-256 at 3,397 MB/s and MD5 at 974. Apple's /usr/bin/python3 3.9.6, linked to LibreSSL 2.8.3, got the same 3,397 for SHA-256 but 1,289 for SHA-1 and 978 for SHA-512, the same pattern as the bundled openssl. BLAKE2b, often recommended as a fast modern hash, did 1,486 MB/s: faster than MD5 but well behind SHA-256 here. SHA3-256 did 1,142.

For short inputs, a million 32-byte digests with hashlib.md5(msg).digest() took 0.245 seconds and hashlib.sha256(msg).digest() 0.216 on Homebrew's Python. At that size Python's own call overhead is most of the time, so the algorithm barely shows.

What to run on a Mac

• Checksumming files: use SHA-256. On Apple silicon it is the fast option as well as the safer one. There's no speed reason left to pick MD5 for new work.
• macOS 15 or later: sha256sum file runs the built-in /sbin tool at full speed.
• Older macOS, or scripts that must run anywhere: openssl dgst -sha256 file was as fast as anything here, with the built-in LibreSSL too. Keep shasum -a 256 as the fallback that always exists, and know it costs about 4 times as long.
• SHA-1 or SHA-512 for compatibility: use /sbin/sha1sum or /sbin/sha512sum, or Homebrew's OpenSSL. The built-in LibreSSL ran those at about half the accelerated speed.
• Lots of files: one call with many arguments, and xargs -P for big ones.

One limit on all of this: every number is from a warm cache, and I didn't measure cold reads. When a file comes off a drive that reads slower than the hash runs, the drive sets the pace, and on a slow external disk the choice of tool or algorithm may not change the wall-clock time at all. The same split between the bundled LibreSSL and Homebrew's OpenSSL showed up in a different way in Mac verify error: invalid password, and Apple Archive vs zip has another set of single-core versus multi-core timings from this machine.

FAQ

Is MD5 faster than SHA-256?

Not on Apple silicon. On a Mac mini M4, OpenSSL 3.6.4 hashed 16 KB blocks at 3,356 MB/s with SHA-256 and 979 MB/s with MD5, and Python's hashlib gave 3,397 against 974 MB/s on a 1 GiB buffer. The M4 has hardware instructions for SHA-256 and none for MD5. MD5 can still be faster on CPUs without SHA instructions and in software-only implementations.

Why is shasum so slow on Mac?

The shasum in /usr/bin is a Perl script that uses the Digest::SHA module, which is portable C and does not use the CPU's SHA instructions. On a Mac mini M4 it hashed a 1 GiB file with SHA-256 in 1.80 seconds, while /sbin/sha256sum took 0.45 seconds and openssl dgst -sha256 took 0.42 seconds. Each run also took about 7.9 ms against 1.4 ms for /sbin/sha256sum, because Perl has to start, so calling it once per file in a loop is slow.

What is the fastest way to get a SHA-256 checksum on a Mac?

Run sha256sum on macOS 15 or later, or openssl dgst -sha256 on any version. Both reached about 2.4 to 2.5 GB/s on a cached 1 GiB file on an M4. For many files, pass them all in one call, and for several large files run separate processes in parallel with xargs -P, which cut 4 GiB from 1.77 to 0.52 seconds in one test.

Method: all runs were on 2026-10-09 between 21:00 and 21:40 KST on a Mac mini M4 (Mac16,10, 10 cores, 16 GB, macOS 26.4.1 build 25E253) over SSH as a normal user. The test file was 1 GiB from /dev/urandom on the internal APFS volume, read once before timing; each tool ran three times and the 1 GiB results show the median wall-clock time from Python's perf_counter, including process start. openssl speed ran with its defaults for LibreSSL and with -seconds 1 and -seconds 2 for OpenSSL 3.6.4. The small-file test used 2,000 files of 4 KB, and the parallel test four separate copies of the 1 GiB file. Python results hash a buffer already in memory. Stack Exchange view counts and answers were read through the public API the same evening. I didn't test Intel Macs, other M-series chips, cold reads from disk, or macOS versions other than 26.4.1, and no tool was installed for this post; b3sum and xxhsum, often suggested for speed, weren't on the machine.