(edit) This assumes "ideal" hash function design (a one-way function with no internal structure). Actual implementations approximate this, and may have flaws which make them more predictable than they should be.
According to Wikipedia (summary bar on the RHS), "No actual collisions have yet been produced" for SHA-1. The best we've done is find algorithms that "should" find collisions eventually. SHA-1 has predictable collisions (SHAttered), but these collisions are definitely not the shortest, because they involve a prefix longer than the hash itself.
Since the point of a hash function is that any change (even a single bit) should change the whole result in a basically pseudorandom way, you're essentially looking at the birthday problem.
The table on this Wikipedia page lists the tradeoff between how many inputs you have and how worried you should be about a collision. This other table here lists the "security" of each hash (in bits).
An example calculation: for SHA-512, with 256 bits of security, you have to be looking at 10^32 before you start to get problems. log2(10^32)
is about 106 bits, which means you should start worrying about collisions after about 13 bytes. However, if you're picking them randomly, you might have other issues at that point, like your electricity bill and the death of the Sun.