Short answer: Code → Download ZIP and Source code (zip) supply repository snapshots. For a Windows app, follow the developer’s documented package route. A ZIP may also hold a runnable application, and an EXE may be portable: identify the intended file instead of relying on its extension.
File inspection — 12 October 2026 UTC: We downloaded the two Rufus files named below from links on the official Rufus site, counted archive entries and inspected the executable’s Windows signature without launching it. We also read the PowerToys release asset list and Microsoft installation instructions; we did not download or install PowerToys. This is a file-choice demonstration, not a malware scan or application test.
First identify which download you actually chose
GitHub’s archive documentation describes these downloads as snapshots of a branch, tag or commit. A maintainer’s application package is a separate choice.
| What you selected | What to check next |
|---|---|
| Code → Download ZIP | Read the project’s installation instructions. You downloaded a repository snapshot, not necessarily a built application. |
| Source code (zip) or Source code (tar.gz) | These generated archives can appear beside application files under Assets. Look for the publisher’s named Windows download. |
| A named .exe or .msi release file | Match the documented OS, architecture and installation scope; verify the exact file before deciding to run it. |
| A named portable .zip release file | Check that the publisher calls it a runnable package and documents its contents. ZIP does not automatically mean source. |
| Only source downloads are offered | Check for an official store/package route or a documented build workflow. A Windows binary may not have been published. |
How to find the intended Windows release file
- Establish the owner. Start with the project’s official website or publisher documentation and follow its repository link. Our official-source guide explains why a GitHub hostname alone cannot establish which project or publisher you found.
- Read Install or Download in the README. Some projects direct normal users to a store, their own website or a package manager. Follow that documented route rather than building code just because it is visible.
- Open the recommended release and expand Assets. Check its release label and notes. GitHub’s release documentation explains that release files and generated source archives can be presented together. Do not select the bottom source entry merely because it says ZIP.
- Match the complete filename. Check Windows versus another OS, x64/x86/ARM64 where offered, installer versus portable, and user versus machine installation. A newer preview above a stable release is not automatically the intended stable download.
- Verify before use. Compare the selected file with the publisher’s exact asset name, checksum when supplied, and signing information where applicable. A matching checksum or valid signature does not prove that every use is safe.
A real example: Rufus source ZIP versus the runnable EXE
The official Rufus page has separate Download and Source Code sections. On the inspection date it linked the x64 rufus-4.15.exe under Download and a v4.15 source ZIP under Source Code. Rufus says its executable runs without a separate installation; calling every EXE a setup installer would be misleading.
| File and source | Observed result |
|---|---|
| v4.15 source ZIP linked by Rufus | 7,829,971 bytes; 816 non-directory entries, including 221 files ending in .c and five ending in .exe. The archive includes src/rufus.c, README.md and build files. |
| rufus-4.15.exe, x64 download | 1,989,992 bytes. Windows Get-AuthenticodeSignature reported Valid, with Akeo Consulting as the signer. We did not start the executable. |
The source ZIP’s five EXE entries are under res/freedos, res/hogger and res/setup. Finding an EXE somewhere in a source tree is therefore not enough to identify the main app. Do not try those embedded files as substitutes for the documented Rufus download.
Show the measured SHA-256 values and inspection limits
Source ZIP: 21cf189915032c3094abbb1e9cf4103866340daf01f8ca12a7020e66f516ea9c.
Named x64 EXE: 84c8a437f8af89257524478489e5c85f1edf25f761d299e2bcde46ac0afbe106.
These are our measurements of the downloaded bytes on 12 October 2026, not a publisher checksum for any file with a similar name. GitHub explains that an archive’s compressed bytes can change while its contents remain equivalent; a tag or branch can also move. An outer ZIP mismatch alone does not diagnose malware. We read the ZIP directory without extracting or executing its files.
Read the original observation record for URLs, sizes, entries and the measured signature result.
Use our Rufus download guide to choose the named architecture and portable option. File selection and writing a USB drive are separate tasks.
PowerToys: architecture and installation scope are separate choices
Microsoft’s PowerToys instructions direct users to GitHub release assets or Microsoft Store and distinguish x64/ARM64 and per-user/machine-wide installers. The release marked latest by the public GitHub API when we checked was v0.101.2362.0, with prerelease=false.
That release lists four installer choices: PowerToysUserSetup-0.101.2362.0-x64.exe, PowerToysUserSetup-0.101.2362.0-arm64.exe, PowerToysSetup-0.101.2362.0-x64.exe and PowerToysSetup-0.101.2362.0-arm64.exe. The UserSetup name identifies user scope; x64 or ARM64 identifies processor architecture. Neither is interchangeable with the automatically generated Source code archive.
We inspected the release listing, not the four installer files or their install outcomes. Check the PowerToys guide and the publisher’s current release before downloading; the dated version here is an example, not a promise that it remains latest.
If the release offers no Windows application file
A public repository does not promise a prebuilt Windows program. Its documented output may be a library, script, browser project or application for another platform. Check the README’s supported platforms and download route. If the publisher supplies only build instructions, that is a different task with toolchain and dependency requirements; repeatedly extracting the same source ZIP will not create a missing published binary.
If no applicable package is documented, stop at that evidence. Do not fill the gap with a similarly named EXE from an unrelated repository or a random build shared in a comment. State the owner/repository, release tag, exact downloaded filename and expected OS when asking for help. Avoid posting passwords, keys or personal paths.
Before you run the file you chose
Keep the original name and source URL. Read Windows signing information with our signature guide and compare an exact publisher hash with our local SHA-256 checker. These checks answer different questions from whether you selected the right package. A source archive may have no application signature, and a legitimate open-source release may be unsigned; neither observation alone is a malware verdict.
Common questions
Should I rename a source ZIP to EXE?
No. Changing the filename extension does not turn source files into the compiled application. Return to the developer’s documented download route.
Does an EXE in the archive prove I found the program?
No. Our Rufus source inspection found five EXE files in resource folders. Identify the file specified by the publisher instead of launching an arbitrary executable.
