How to check if an .exe is safe before you run it
By Andrew Nakas · Published September 22, 2026 · ~9 minute read
You have downloaded something ending in .exe and you are not certain about it. Perhaps the site looked improvised, perhaps a colleague sent it, perhaps you searched for a tool and the first three results all offered a different installer with the same name.
Most advice at this point is "scan it", which is not wrong but is a small part of the answer. A Windows executable declares a great deal about itself before it runs a single instruction, and reading those declarations costs nothing. What follows is what you can learn, in rough order of usefulness, and — the part usually left out — what each thing is actually worth as evidence.
Start with where it came from
This remains the highest-value check and no amount of file analysis replaces it. The vendor's own site beats an aggregator; an aggregator that wraps the download in its own installer is a bad sign on its own; and a link that arrived unprompted in a message is the single most common way people get caught, whoever appears to have sent it.
If the program is open source, prefer the project's own release page. If the project publishes checksums, compare them — that is the only method on this page that proves the file is byte-for-byte what the author published.
Is it signed, and by whom?
An Authenticode signature binds the file to a certificate someone had to buy with an identity attached. A signed file that has been altered fails verification, so a valid signature does tell you the bytes are as the signer left them.
What it does not tell you is that the signer is trustworthy. Certificates are purchased, and they are stolen; signed malware exists and always has. Treat a signature as identification, not endorsement — it says who to blame, not that there is no one to blame. On Windows you can see it under Properties → Digital Signatures. Elsewhere, the EXE viewer will at least tell you whether one is present, though no browser can verify a certificate chain.
Unsigned is not damning. Most small open-source utilities are unsigned, because certificates cost money. It is one input.
What does it say about itself?
Executables carry a version resource: company name, product name, file version, copyright line, original filename. This is what Windows shows in the Properties dialog, and it is the fastest way to notice that a file called setup.exe claims to be something else entirely, or that its "original filename" does not match the name you downloaded.
Bear in mind what these strings are. They are text that whoever compiled the file typed into a resource script. Anyone can put "Microsoft Corporation" there. They are excellent for identification and worth nothing as proof.
What does it ask Windows to do?
This is the most interesting part, and the least known. A Windows program cannot call a system function without naming it, in plain text, in a table inside the file. Want to open a socket? The file must name ws2_32.dll. Want to read the registry? It must name RegOpenKeyExA. Start another process, install a service, hook the keyboard, encrypt something — each of those is a named import, written down before anything runs.
So you can read, from the file alone, roughly what a program is equipped to do. A small offline image converter that imports networking functions is at least worth a question. An installer that imports service-control functions is telling you it intends to install a service.
Two cautions, both important. First, these APIs are utterly ordinary: every updater talks to the network, every installer writes files, plenty of legitimate software reads the registry. A long list is not an accusation. Second, and more seriously, the absence of a list means nothing at all — see the next section.
Is it packed?
Packers compress an executable and unpack it in memory when it starts. UPX is the common legitimate one; there are many commercial protectors too. Compression makes downloads smaller and makes reverse engineering harder, and both of those are reasons honest software uses it.
It also means that everything in the previous section evaporates. A packed program imports almost nothing — typically just enough to allocate memory and load libraries by name at runtime — and only reveals its real imports once it is already running, which is precisely too late. So "this file imports almost nothing" is not reassurance. It is the opposite: it means static inspection cannot see anything, and you should lean harder on provenance and on scanning.
You can spot packing without recognising the specific packer, by measuring entropy — how random the bytes look, on a scale of 0 to 8. Ordinary compiled code sits around 6. Compressed or encrypted data sits above 7.2. A program whose executable section is at 7.9 has been packed, whatever it is called.
Is it even the program?
Very often the thing you downloaded is a wrapper: a small program with an entire archive appended after it. That is what a self-extracting installer is. Worth knowing for two reasons — the thing you actually want is inside, and can frequently be extracted without running anything; and the wrapper's own properties tell you nothing about what it will unpack.
A file where 95% of the bytes sit after the last section of the executable is a wrapper, and that is visible without running it.
Scan it
VirusTotal runs an upload past around seventy engines at once, which is far better than any single scanner including the one you have. If the file has been seen before you also get its history, which is often more informative than the verdicts.
The catch is in the word "upload". You are handing the file to a third party, and if it is a confidential document wrapped in an installer, that is a decision rather than a formality. You can search by hash instead — compute the file's SHA-256 and look that up — which tells you whether the file is known without sending it anywhere.
And calibrate the result. One or two detections out of seventy is usually a false positive, especially for packed software or small utilities that manipulate the system. Fifteen is not.
Run it somewhere that does not matter
Everything above is static. At some point you may simply want to see what the program does, and the answer is to give it somewhere to do it that you do not care about: a virtual machine with no network and no shared folders, Windows Sandbox on Pro editions, or an online sandbox service that will run it and produce a behaviour report.
A browser tab is a partial version of this. The loader here runs 32-bit Windows programs in an emulated environment inside the page, with no access to your real filesystem and no network for the program to reach. It is genuinely a boundary, and it is not a malware analysis lab — it is a reasonable way to see whether an old utility does what it claims.
What none of it proves
There is no static check that establishes a file is safe. Everything on this page is a program's account of itself, and a program that wishes to be misleading is under no obligation to be honest in advance. What these checks are genuinely good for is the ordinary questions — is this the architecture I need, is it a wrapper, does it claim a publisher, is it signed, is it complete, is it hiding — and those turn out to be what most people actually want to know.
Used well, inspection raises or lowers your confidence. It does not settle it. If the answer matters, the order is: trust the source, verify the checksum, scan the hash, and run it somewhere disposable.
The EXE viewer does the static half of this in the browser — signature presence, publisher strings, imports, packing, entropy, whether it is a wrapper — without uploading the file anywhere and without running it.