MD5 is broken - here is what to use instead

Mike Knights — Fri, 08 May 2026 09:34:09 +0000

MD5 is everywhere. It is in legacy codebases, old tutorials, and still used by developers who have not stopped to check whether it is still appropriate. In most cases it is not.

Here is a clear breakdown of what hash functions are, why MD5 is broken, and what you should use instead.

What is a hash function?

A hash function takes any input - a word, a file, an entire database dump - and produces a fixed-length string called a hash or digest. The same input always produces the same hash. Change even one character and the output changes completely.

SHA-256("hello")  = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("hello!") = ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b

This "tiny input, wildly different output" property is the avalanche effect and is fundamental to why hash functions are useful.

Hash functions are one-way. You cannot reverse a hash back to the original input. This makes them useful for verifying data without storing the data itself.

The algorithms compared

Algorithm	Output	Status	Use today?
MD5	128-bit / 32 chars	Broken	Checksums only - never security
SHA-1	160-bit / 40 chars	Broken	Legacy only - avoid
SHA-256	256-bit / 64 chars	Secure	Yes - general purpose
SHA-512	512-bit / 128 chars	Secure	Yes - where extra strength is needed

Why is MD5 broken?

A hash function is considered broken when researchers can produce a collision - two different inputs that produce the same hash output.

MD5 collisions can be generated in seconds on consumer hardware. Researchers have demonstrated collision attacks that produce two entirely different files with the same MD5 hash. SHA-1 was formally broken in 2017 with the SHAttered attack.

SHA-256 has no known practical collisions. Its 256-bit output space is so vast that even with all the computing power on Earth, brute-forcing a collision would take longer than the age of the universe.

What is MD5 still acceptable for?

MD5 is still fine when:

You need a fast, non-cryptographic checksum to detect accidental corruption (not adversarial tampering)
You are checking whether a cached resource has changed
The context has no security implications whatsoever

MD5 is not acceptable for:

Password hashing (use bcrypt or Argon2 - not any raw hash function)
File integrity verification where tampering is a concern
Digital signatures
Any security-sensitive context

What should you use?

For file integrity / checksums: SHA-256. It is fast enough for almost all use cases and is the standard for software distribution (you see it on download pages as the verification hash).

For password storage: Never use a raw hash function. Use bcrypt, Argon2id, or scrypt. These are purpose-built password hashing algorithms that are deliberately slow and include salting. See How Passwords Are Hashed for the full explanation.

For HMAC / API signing: SHA-256 via HMAC (HMAC-SHA256).

For digital signatures: SHA-256 (part of RSA-SHA256 and ECDSA-SHA256).

Generate hashes online

You can generate MD5, SHA-1, SHA-256, and SHA-512 hashes instantly in your browser - nothing is sent to any server - at:

For a broader explanation of how hash functions work, see What Is a Hash Function?

TL;DR

MD5 and SHA-1 are cryptographically broken - collisions can be generated deliberately
Use SHA-256 for checksums, file integrity, HMAC, and signatures
Never use any raw hash for passwords - use bcrypt or Argon2id
SHA-256 has no known practical collisions and is the current standard

Stop using UUID v4 as your database primary key

Mike Knights — Fri, 08 May 2026 09:31:07 +0000

I spent a while wondering why inserts on a particular table were getting slower as it grew. The table had a UUID v4 primary key and a few indexes. The data wasn't huge - a few million rows - but write performance was noticeably degrading.

The problem wasn't the query. It was the UUID.

What's actually happening

UUID v4 is random by design. Every new ID lands at a completely unpredictable position in the B-tree index. So every insert causes the database to find that random position, potentially split a page to make room, and rebalance. Do this millions of times and you end up with a fragmented index, lots of wasted space, and slower writes.

With an auto-incrementing integer, every new row goes at the end. No splits. No rebalancing. The index stays tight.

UUID v4 throws all of that away.

UUID v7 fixes it

UUID v7 was standardised in RFC 9562 (May 2024). The important bit: the first 48 bits are a Unix millisecond timestamp. Because time only moves forward, v7 UUIDs sort chronologically - new ones are always greater than old ones.

The database sees the same sequential insertion pattern it gets from an integer primary key. No fragmentation. You keep all the benefits of a UUID (globally unique, no central registry, works across distributed systems) without the index penalty.

It looks identical to v4:

018f6e3a-2b4c-7d8e-9f0a-1b2c3d4e5f6a

Drop-in replacement. Same format, same length.

When v4 is still the right call

If the ID is exposed publicly and you don't want to leak when a record was created - use v4. The timestamp in v7 is extractable, which can be a privacy concern for things like user account IDs.

For internal records, order IDs, event logs, anything where sequential ordering is fine - v7.

Language support

Most stacks have it now. Node.js uuid package has uuid.v7() since v9. Python 3.14 has it in stdlib, or use the uuid7 package. ramsey/uuid in PHP, google/uuid in Go, Prisma has uuid(7) as a default option. PostgreSQL has the pg_uuidv7 extension.

If you're starting a new project, just use v7. If you have an existing table with v4, you don't need to migrate - new rows can switch immediately and the index tightens up gradually as old pages get rewritten.

For generating both versions with various formatting options, datatoolkit.net/uuid does the job. There's also a more detailed writeup on the performance implications at datatoolkit.net/learn/uuid-v4-vs-v7.

DEV Community: Mike Knights