By Eric L.
09/13/2026 · 6 MIN READ

A swapped file looks like the real one: same name, same size, same icon.

The only way to tell them apart is the checksum (a short fingerprint of the contents: change one byte and the whole fingerprint changes). If the sum of the file you downloaded matches the one the author published, it's the same file. If it doesn't, it's a different one, and you don't run it. Here's where swaps come from, how to compute the sum in a second, and where to get the reference so the check actually means something.

SAME NAME, DIFFERENT FILEFIG. 01
author's file   a3f9…
your file       a3f9…   match
your file       71c0…   different file
   └─ name and size can match,
      the sum can't
The four characters here stand in for the full 64: the tool compares every one before it calls anything a match.

What a hash is, in plain terms

Take any file, a gigabyte if you like, and run it through a formula. Out come 64 characters, always the same 64 for the same file. Change one byte in the file and all 64 characters change, with no relation to the old ones. You can't rebuild the file from those characters, but you can compare two files by them in a second without comparing the files themselves.

ONE BYTE CHANGES ALL 64 CHARACTERSYour fileany sizeSame file againany computerOne byte changedthe rest is the sameSHA-256one open formulaa3f9…64 charactersa3f9…the same 64: match71c0…all 64 change, no relationOne way only: the 64 characters can't be turned back into the file.
The same file always gives the same sum; change one byte and every character changes.

That's a hash, also called a checksum, also called a fingerprint. The author computes it from their file and publishes it. You compute it from yours and compare. Match means the files are identical down to the last byte. The formula is open and the same for everyone, so a sum computed on Windows can be checked against one computed on a Mac or in a browser.

How a downloaded file gets swapped

There's a road between the site and your disk, and the file can get replaced along it. A mirror that "just downloads faster." An infected router in a hotel. A carrier injecting its own ads into unencrypted pages. Public Wi-Fi where someone's sitting in the middle. And the most common case: you downloaded the file not from the official site but "from another address with the same thing," figuring it was the same thing.

HTTPS protects against a lot of that, but not the last one. If you went to somebody else's site yourself and downloaded somebody else's file yourself, the encrypted channel faithfully delivered you a fake. The sum answers the question flat out: is this the file the author released, or not.

WHERE A DOWNLOAD CAN BE SWAPPEDAuthor's siteYour diskmirrorhotel routercarrier adspublic Wi-Fion the road: HTTPS protects against a lot of this● THE CASE HTTPS CAN'T CATCHAnother addressyou went there yourselfHTTPS: encrypted, intactYour diska fake, delivered faithfullyOnly the sum from the author's site tells the real file from the fake.
HTTPS guards the road, but not a fake you fetched from the wrong address yourself.

For VPN apps this matters more than usual. A file that's about to get rights to all your traffic is worth checking before install, not after. Why an APK from outside the store is its own risk is in how to set up a VPN on Android.

How to check a SHA-256 checksum

Open the file checksum tool and drag the file onto it. It computes SHA-256 (the standard fingerprint algorithm, 64 characters), with SHA-1, SHA-512 and MD5 a click away if that's what the author published. The file isn't uploaded anywhere: it's read in the tab's memory, and no network requests happen, which you can confirm in the Network tab of your browser's developer tools.

If you've got a reference sum, paste it into the field next to it: the page will say "match" or "no match" on its own, so you don't have to compare 64 characters by eye.

No browser needed either, if you're on a computer:

Windows:  certutil -hashfile file SHA256
macOS:    shasum -a 256 file
Linux:    sha256sum file

Same result on every system. That's the whole point: the sum depends on the contents, not on who computed it or with what.

Where to find the official checksum

This is where people get it wrong most often. The reference sum has to come from a source you trust, not from the same place you got the suspicious file. If the file was swapped on a mirror, the sum next to it was swapped too, and they'll "match." The check means nothing then.

The right way: file from wherever, sum from the author's official site. We publish a .sha256 file next to every one of our downloads: 404vpn.apk.sha256, 404vpn-macos.dmg.sha256, tunnel.apk.sha256. That's the reference. Downloaded the app from any mirror, took the sum from the download page, compared.

WHERE THE SUM COMES FROMFIG. 02
file and sum: one mirror     proves nothing
file: mirror, sum: author    real check
file and sum: author's site  real check
   └─ if the file isn't from the author,
      the sum has to be
The middle row is what almost everyone actually does, and it still counts as a real check.

SHA-256 checksum doesn't match: what it means

That it's not the same file. The reasons can be harmless or not, and telling them apart is easy.

Harmless. You downloaded a different version: the author updated the file and hasn't updated the sum on the page yet, or the other way around. The download didn't finish. The browser unpacked an archive on the fly. In all of these, downloading again from the official site gives you a match.

Not harmless. You downloaded again from the same place, the sum still doesn't match the author's, and the file from the author's own site does match. So that place is serving a different file. What's in it you won't find out, and you don't need to: delete it without running it.

THE SUM DOESN'T MATCH: WHAT NEXTNo matchyour sum ≠ author'sDownload againand compare againNow it matchesnew version, unfinished download,archive unpacked: harmlessSame place, still differentthe author's own file matchesdelete it, don't run it
One more download from the official site tells a harmless mismatch from a swapped file.

Simple rule: a mismatch isn't "look again more carefully," it's "don't run it until it matches."

What the sum doesn't check

The sum confirms the file hasn't changed since the author computed the reference. It doesn't say the author is honest, and it doesn't say the file has no bugs. If you trust the author, the sum guarantees you got their file. If you don't, the sum won't help: it'll confirm the authenticity of a malicious file from someone you shouldn't have trusted with the exact same precision.

And it isn't a signature. A signature also answers "who released this," while a sum only answers "is this the same thing or not." For a downloaded app that's usually enough, as long as the sum came from a site you trust.

Honestly, here's what I'd do: not check everything. I'd check three categories: apps that get broad permissions (VPN, antivirus, anything with system access), files from mirrors and torrents, and anything that came through a link from a stranger. It takes a second, and it can save a lot.

WORTH THE MINUTE WHEN...FIG. 03
[ ] broad permissions (VPN, antivirus)
[ ] file from a mirror or torrent
[ ] file from a stranger's link
[ ] sum from somewhere else
    └─ skip that last box and the
       first three do not matter
Most downloads never need this. The ones asking for system-level access are exactly the ones that do.

If the sum didn't match and you can't tell whether the reason is harmless, give an AI both sums and the file's history.

Prompt for an AI
Help me figure out why a file's checksum
doesn't match.

File: (what it is, where it was downloaded from).
Reference taken: (from the author's site / next
to the file / don't know).
My sum: (paste). Reference: (paste).
Downloaded again: (yes, same sum / no).

Tell me whether this looks like a different
version or an incomplete download, or like a
swap, and what to do next. Don't tell me to
run the file.

In short

Name and size can be faked, the sum can't. Drag the file in, get the SHA-256, compare it with the reference from the author's site. Match means it's the real file. No match means don't run it. The big mistake: taking the reference from the same place the suspicious file came from, because then the check means nothing.