A hash collision occurs when two different inputs produce the same hash value. Collisions are unavoidable for any hash function, because the function maps a large or unbounded input space onto a smaller fixed-size output. By the pigeonhole principle, once there are more possible inputs than possible outputs, some outputs must be shared. The question is never whether collisions exist, but how a system copes when they happen.
In a hash table, collisions mean two keys want the same bucket. The MIT 6.006 hashing lecture describes the two standard remedies. Chaining stores all keys that hash to a bucket in a small list attached to that bucket, so a collision just adds to the list. Open addressing instead probes for another empty slot in the array according to a fixed rule. Both keep a hash table fast as long as collisions stay rare, which is why an even hash function and a table that is not too full both matter.
For cryptographic hash functions the stakes are different. Here collisions are still inevitable in principle, but the function is designed so that finding even one pair of colliding inputs is computationally infeasible. NIST’s FIPS 180-4 lists collision resistance as a required property of the Secure Hash Standard functions, because a digital signature or integrity check is only trustworthy if no attacker can produce two messages with the same digest.
This is why the discovery of practical collisions in older cryptographic hashes is treated as a break. When researchers found ways to generate colliding inputs for hashes such as MD5 and SHA-1, those functions could no longer be trusted for security, even though they remain perfectly fine as fast, non-cryptographic hashes for tables and checksums.