Upload Looks Corrupt: Compare Hashes at Both Ends

Recipients who cannot open an uploaded file often hear that the VPN corrupted it. That is a hypothesis, not an observation, and it is testable. Before touching the tunnel, establish whether the object now stored at the destination differs from the object that was supposed to be sent. Everything else follows from that answer.

Start with the intended bytes, not the complaint

Pick a harmless file that reproduces the problem, or the actual file if policy allows it to leave the source environment. Record two things before transfer: the exact size in bytes and a modern content hash. Filenames, timestamps and previews are metadata, and none of them identifies content.

Compute the hash with an algorithm both ends can run, and write down which one you used. A comparison between SHA-256 and MD5 is not a comparison, and neither is a comparison between two different files that happen to share a name.

PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash                                                        Path
----                                                        ----
9F2C...                                                      C:\uploads\report.csv

Microsoft's Get-FileHash reference documents the command and its algorithm parameter, which is the part people skip when a comparison produces a meaningless mismatch.

One hash per stage, same algorithm

Now compute the same algorithm on the stored object where it finally lives, using an authorised method rather than a copy that passed through another tool. Saving the received file locally and hashing that copy adds a step you have not tested.

If the service exposes an integrity value of its own, treat it as a separate observation. A provider-reported checksum can tell you what the provider believes it stored, and it is not the same claim as what your client sent.

Three outcomes are possible, and they point in different directions. Equal hashes mean the bytes arrived unchanged. Different hashes with a known conversion mean the service intentionally produced a new object. Different hashes with no conversion mean something between the two points altered the content, and the next step is to find the earliest boundary where that happened.

Separate transfer failure from transformation

A partial upload and a corrupted upload look identical in a file browser and are different faults. Check whether the transfer completed: an application log showing an aborted request, a stored file whose size is a prefix of the source, or an object that is actually an error page saved under the expected extension all indicate an incomplete transfer rather than altered bytes.

Transformation is the other common explanation. A service that recompresses images, rewrites CSV line endings or converts a document will legitimately produce a hash that differs from the source, and that is not corruption. Compare the stage that claims to be the faithful copy, not the final presentation format.

Delay and loss belong to a third category. They can make a client time out, retry or give up, and none of that implies that bytes accepted by the server were silently changed. Look at the transfer result before attributing anything to the tunnel.

Try a second path without changing everything

If the hashes really differ and no conversion is involved, repeat the same file, client, protocol and destination over another supported path, such as a local network instead of the VPN. Change one variable. Changing the client, the endpoint and the tool at once gives you a result you cannot attribute.

Keep the comparison honest in both directions. A hash tells you that two points disagree or agree about content; it does not tell you which side is trustworthy, so keep the expected value and the verification inside the trust model you actually rely on.

Finish with a specific sentence in the ticket: the transfer stopped early, the application transformed the object, storage changed it, or the bytes agree and reading them is the failure. Each of those has a different owner, and none of them is the VPN by default.