To get to the real problem:

If the file size was off too, it'd be an easier thing to figure out. You don't mention if its exact same or not.

There are times in software where to get the right answer, one would have to debug the code and step through it until finding the answer with comparison between changed and original. Its a programmers thing. This would find the exact problem and the problem can be different from what anyone expects. Some could expect something like a RAM or storage problem but it could just be a super rare WinSCP problem.

WinSCP logs can in theory explain it. Logs were also never mentioned.

There's various other slower ways to poke at it like transfer using the client from the other side to the computer you were sending from could show something.

Also, you said FileZilla, etc were fine. Even though hardware problems can show up in rare ways such as Intel's more recent oodle problem, I would not right off blame hardware here.

Of course, throwing other hardware at it is good for a test to help narrow down. But, that's all its good for here.

Thanks for sharing your findings.

I may have found a solution, although no understanding the cause of failure still.

The issue may have stemmed from the older hardware/instability in it's setup, 4 dimm ram, bios, etc. I acquired newer hardware to mimic what my original home server was; AM5 socket and DDR5 ram. I also learned about ReFS on windows 11 and converted a drive to it. My uploads and downloads now have matching checksum on any transfer size over SFTP.

I may also be wrong about ECC CPU support, ECC supported memory is extremely expensive right now; The memory in the computer I gave away definitely was not ECC supported.

I am very much at a loss. Any advice, guide/instruction links, or anything else would be greatly appreciated. I have very little practical knowledge on file transfer and am at my limit of understanding nor being able to find information online about my specific issue here that is not 15-20 year old forum posts.

I should have included this information in the first post.
The home server currently is Windows 11, using openSSH optional feature for SFTP. SFTP dir is on a WD RED hard drive.

If the hardware age, ram config, etc matters to this issue:

CPU is an i7-8700k with a 4 dimm 32gb ram. The bios was updated to the newest one for 2026.
The hardware I gave away had an R7 9700x with 2 dimm dual channel 32gb ram.

While on the R7 9700x, I used SMB and don't recall any issues to this extent. Although it was awhile ago.

I may have found a possible cause to the error, the i7-8700k im using for the home server does not support ECC. While the hardware I gave away to family had a cpu with ECC support. This could possibility explain the errors. I wrongly assumed SMB worked correctly as well as the other FTP clients as after more testing they are had a chance of corrupting data.

When i upload large archive files to a home server, the data gets messed up somehow. The md5/sha256 hash does not match the original file on the main computer. More bizarre when downloading the same archive file the checksum is different each time. This occurs from a zerotier vpn and local connection.

I have tried several different 7z and zip compression levels, including just using store. I have tried moving the file uncompressed/unpacked back and forth with similar results. High levels of compression results in 7zip reporting data error, while normal and store report CRC error.

I tried default WinSCP settings, binary transfer mode, turning off optimization of buffer size.

This issue is not occurring on cyberduck, filezilla, or an SMB share on windows.