MD5 is cryptographically broken, and has been for a long time: practical collision attacks, where two different inputs produce the same hash, have been demonstrated since 2004 and have only gotten cheaper since. That single fact rules it out for anything where an attacker could benefit from crafting a second input with a matching hash — password storage, digital signatures, certificate fingerprints, or any check meant to prove a file has not been tampered with by someone motivated to tamper with it.
The reason this keeps being confusing is that MD5 is not broken for every property a hash function has, only for collision resistance. It is still extremely fast, it still produces a consistent fixed-length output, and it is still perfectly good at detecting *accidental* corruption — a file that got truncated in transfer, a download that didn't complete, two versions of a document that differ by a single character. None of those scenarios involve an adversary deliberately constructing a matching input, so the broken property never comes into play.
That distinction is why MD5 checksums still appear on download pages for software and why some tools still use it internally for non-adversarial deduplication or cache keys. It is a reasonable choice there precisely because nobody is trying to defeat it. It is a dangerous choice anywhere a malicious party could supply or influence the input.
For anything security-relevant, SHA-256 is the practical default today: fast enough for almost any purpose, with no known practical collision attack, and supported everywhere MD5 is. For password storage specifically, neither MD5 nor plain SHA-256 is the right tool regardless of collision resistance, because both are designed to be fast, and fast is the wrong property for hashing something an attacker will try to brute-force — a dedicated password hashing function that is deliberately slow is what that case actually needs.
The short version: ask whether anyone has a reason to want a specific collision, not just whether the file matches. If the answer is no, MD5 for accidental-corruption checks is fine. If the answer is yes, or if the use is anything security-adjacent, move to SHA-256 or a purpose-built function rather than defaulting to whatever hash a tutorial happened to use.