Before you open a download, your browser has checked its URL and, for some file types, its hash against a reputation service, your operating system has tagged it as coming from the internet, and your antivirus has scanned it on write. Those checks are good against known threats and poor against new ones, so add an independent scan and a type check before opening anything that can run code.

What happens between the click and the file

A download passes through more checks than most people realise, and knowing what each one does tells you what it does not. In order:

  1. URL reputation. Before or during the download, the browser checks the URL against Safe Browsing (Chrome, Firefox, Safari, Edge in some modes) or SmartScreen (Edge). A known-malicious or phishing host is blocked outright.
  2. Download protection. For file types that can run code, Chrome and Edge send metadata such as the file's hash, size, signer and referring URL to a reputation service, which may answer "dangerous", "uncommon" or "safe". Firefox does the same against Google's application-reputation lists for executables. Files judged dangerous are blocked; uncommon ones prompt.
  3. Origin tagging. The saved file is marked as coming from the internet: on Windows through an alternate data stream named Zone.Identifier (the Mark of the Web), on macOS through the extended attribute com.apple.quarantine.
  4. On-write antivirus scan. Microsoft Defender or your installed product scans the file as it is written and quarantines a signature match. macOS's XProtect checks against Apple's signature list when a quarantined file is first opened.
  5. Open-time policy. Windows SmartScreen checks an executable's reputation when it is run; Gatekeeper verifies signing and notarisation on macOS; Office opens marked documents in Protected View and blocks their macros; Explorer warns before running a marked script.

Every one of these is useful and every one has holes, which is why the guides across the malware scanning hub keep returning to the same advice: the built-in layers handle the known; you handle the rest.

Where the origin mark lives, and why attackers attack it

The mark is the linchpin, because so many later protections depend on it. You can see it:

# Windows PowerShell
PS> Get-Content .\report.docx -Stream Zone.Identifier
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://example.org/downloads/
HostUrl=https://cdn.example.org/files/report.docx

# macOS
$ xattr -p com.apple.quarantine report.pdf
0083;66e4a1b2;Safari;A1B2C3D4-0000-4000-8000-000000000000

ZoneId=3 means Internet zone. Office reads it and refuses to run macros; Windows reads it and shows the "publisher could not be verified" warning; SmartScreen reads it to decide whether to check reputation. Remove the mark and all of that goes quiet. Attackers therefore deliver payloads inside containers where the mark historically did not propagate: ISO and IMG disk images that Windows mounts as a drive, VHD files, and archives opened by third-party tools that do not copy the attribute to extracted files. Microsoft changed Windows in late 2022 to propagate the mark into mounted ISO contents and Office to honour it inside common archives, but tools vary, and a payload that appears without a mark is as trusted as one you created yourself. When you see an ISO or IMG offered as a "document", that is the reason.

The gaps, by file type

DownloadBrowser checkOS antivirusOpen-time protectionRemaining gap
.exe / .msi from a known siteHash and signer reputationSignature scanSmartScreen / GatekeeperNew unsigned builds prompt but are not blocked
.docx / .xlsmUsually none beyond URLSignature scanProtected View, macro blockRemote templates, exploits, user clicking through
.pdfURL onlySignature scanReader sandboxPhishing links, launch actions in a desktop reader
.zip / .rar / .7zURL, sometimes a scan of contentsScans on extractionMark may not survive extractionEncrypted archives, nested layers
.iso / .imgURL onlyScans the image; contents on mountMark propagation is version-dependentHistorically none; still tool-dependent
.html / .htmURL onlyRarely flaggedNone: it is opened in the browserHTML smuggling assembles the real file locally
.lnk / .js / .vbs / .htaTreated as dangerous typesSignature scanWarning dialogObfuscation; users accept the dialog

Two rows deserve emphasis. HTML smuggling sidesteps the download check entirely: the "download" is an HTML page, which every filter allows, and JavaScript inside it decodes an embedded blob and triggers a save from within the browser, so the file never crossed the network as a file. Scan.now's HTML smuggling check looks for that pattern. And archives are where on-write scanning is weakest, because the antivirus sees a container it may not fully open, and a password defeats it entirely; the password-protected archive finding is the scanner admitting as much.

What "Enhanced protection" and "deep scan" actually do

Chrome and Edge offer stricter modes. Chrome's Enhanced Safe Browsing sends more data about downloads and pages to Google in real time and, for suspicious files, offers to upload the whole file for deeper analysis. Edge's SmartScreen does similar reputation checks against Microsoft's service. These are worthwhile for most people, with two caveats: they trade some privacy for the extra checks, since URLs and file metadata leave your machine, and they still work on reputation and known-bad patterns, so a targeted or brand-new file can pass. For the privacy side of browser configuration, see browser security settings that matter; the browser scanner shows what your current setup enforces.

Linux, mobile and other cases with fewer layers

The layered picture above describes Windows and macOS with a mainstream browser. Elsewhere the layers thin out. A typical Linux desktop has no on-write antivirus and no origin mark; the browser's URL and download reputation checks still run, and after that the file is simply on disk, so the two-minute habit below is the only check that happens unless you make it happen. On Android, Google Play Protect scans installed apps and sideloaded APKs, and the browser applies Safe Browsing, but a document or archive downloaded to the device is not scanned in any meaningful way until an app opens it. On iOS, downloads are confined by the app sandbox, which is why file-based malware is rare there and why the realistic risk is a phishing page rather than a file. Corporate mail gateways add a layer in front of all of this, and it is worth knowing whether yours opens archives and blocks encrypted ones; the nested EICAR test in the EICAR guide answers that in a minute.

A habit that closes the gaps in two minutes

None of the above requires expertise. The routine below assumes extensions are visible (turn them on: File Explorer View menu on Windows, Finder Settings on macOS) and takes about two minutes for a file that warrants it:

  1. Look at the extension you were given. An executable, installer, script, shortcut or disk image where you expected a document is the answer already.
  2. Check the real type. file name.ext on macOS and Linux, Format-Hex -Count 8 in PowerShell. MZ is a Windows program; PK is a zip or Office file; %PDF is a PDF. A mismatch is decisive.
  3. Scan with an engine that is not the one on your machine. Upload to Scan.now's file scanner, which analyses the file in memory with signature matching, structural analysis and heuristics, and never stores it. Independence is the point: a second engine has different signatures and different blind spots.
  4. Read the findings. A signature match, a disguised executable, an obfuscated script or a smuggled download ends the question. A macro, PDF action or encrypted archive is a question about whether this sender had a reason.
  5. Open in the least capable viewer first. Browser for PDFs, Protected View for Office files, no macros, no content enabled. Escalate only if the content genuinely needs more.

For a download that is an installer you chose to fetch, add one more step: compare its SHA-256 with the value on the publisher's page, as shown in file hashes explained. That catches the case where a mirror or an ad-served "download" button gave you something other than the real installer, which is a common way legitimate software downloads go wrong.

Downloading from the publisher's own site, over HTTPS, from a link you typed or bookmarked rather than clicked in a message, removes most of the risk before any scanner is involved. The scanning habit is for everything else.

Where the habit fits

The browser and operating system layers are real protection and you should leave them on; they stop the bulk of commodity malware silently. The habit above covers the residue: new builds without a reputation, documents whose danger is a macro or a link rather than a signature, archives that hide their contents, and files that arrived stripped of their origin mark. When the two-minute check leaves you unsure, the fuller reasoning in is this file safe takes over, and for the mechanics of what the scanners are doing on your behalf, read how antivirus scanning works.