It can't corrupt files via fragmented or damaged/missing packets. The vast majority of data exchanges over the Internet are transferred via TCP/IP. The way TCP works is that every packet is confirmed by the recipient. e.g.
■Server sends packet #54214 with 1k of data, plus a checksum for that data.
■Recipient receives packet, calculates checksum, confirms it matches checksum sent with data.
■Recipient sends message to server "hey I got packet #54214 ok."
■Server receives acknowledgement, sends packet #54215 with 1k of data plus checksum. (In reality there's usually a small buffer of pre-sent packets, but new packets are not sent until previously sent packets are acknowledged by the recipient.)
■Or Recipient sends message to server saying "hey packet #54214 was corrupt." and server resends it.
■repeat
There are a few file transfer protocols which use UDP (which doesn't use acknowledgement), but they usually have their own error-checking built into them.
That leaves just two ways files can get corrupted in a TCP transfer.
■Corruption which randomly results in a checksum collision (corrupted packet has the same checksum as the original packet). These are exceedingly rare, but do occasionally happen.
■Incomplete file. The download never completed, resulting in a partial file. Since it's partial, the end of the file is corrupt. Certain transfer protocols (like HTTP) can recover from partial downloads. If you restart the download, it notices the already-downloaded file and source file are a different length, and picks up where it left off. Others can't resume and just start over from the beginning.
If you have slow Internet, you're most likely to suffer from the second problem. But any file your browser (which uses TCP/IP) shows as being downloaded successfully should not be corrupt. Though there's a slightly increased chance of corruption if you had to resume the download.
Facebook
Twitter
Instagram