But it is not a universal tag applied to every download. Whether the mark exists depends on the downloading application, the source zone, policy settings, the file system where the file is saved, and sometimes the route by which the file reached the PC. That distinction matters: a missing mark is not proof that a file is safe, while removing a mark is not a malware scan or a trust decision.
The hidden mechanism: an NTFS alternate data stream
MotW is generally stored as a named alternate data stream (ADS) on an NTFS volume. NTFS files have a normal, unnamed data stream—the contents people open and edit—but they can also have additional named streams that conventional file listings do not normally display.
For MotW, the relevant stream is named Zone.Identifier. Its fully qualified form is typically represented as:
filename:Zone.Identifier:$DATA
The stream can contain simple text resembling this:
[ZoneTransfer]
ZoneId=3The ZoneId value represents Windows security-zone information:
- 0: My Computer
- 1: Local intranet
- 2: Trusted sites
- 3: Internet
- 4: Restricted sites
A value of 3 is the familiar internet-origin case. It gives Windows components and applications useful context about where the file came from; it does not, by itself, establish that the file is malicious.
This use of alternate streams may feel obscure, but ADS are not a newly invented download feature. They date to Windows NT 3.1 in 1993, when an original purpose was helping Apple Macintosh clients use Windows NT file servers. MotW is a later and security-focused application of a long-standing NTFS capability.
Why “every download is tagged” is wrong
The simplified story—Windows secretly tags every downloaded file—is appealing, but technically false.
First, MotW depends on the file system. Microsoft states that it applies to files saved on NTFS, not files saved on FAT32-formatted devices. More broadly, the protection is tied to NTFS stream support: when a tagged file is copied to a destination without the needed support, the mark can be omitted and the provenance information lost.
Second, the download client must participate. Internet-facing applications need to use the relevant Windows attachment-handling mechanism or otherwise write the zone stream. Support is not universal across browsers, mail clients, download managers, synchronization products, command-line tools, and custom applications. Two files acquired from the same website can therefore arrive with different metadata if they were obtained through different software or workflows.
Third, Windows does not add the mark indiscriminately for all zones. By default, Microsoft says MotW is added for files from the Internet or Restricted sites zones. Enterprise or user policy can also control whether Windows preserves zone-origin information on attachments. An organization can configure Windows not to mark attachments with that information, which changes how downstream software sees them.
Finally, some cloud and productivity workflows do not behave like a conventional browser download. Microsoft documents examples including OneDrive sync and “Open in Desktop App” paths that do not receive MotW. That can explain why a file opened from an online service produces a warning in one scenario but not another.
The practical conclusion is important: MotW is useful provenance context, not a comprehensive inventory of everything that originated online.
How to inspect a file’s MotW data
If a file is on an NTFS drive, Command Prompt can reveal alternate streams with DIR /R. For example:
dir /r "C:\Users\YourName\Downloads\example-file"
A normal directory listing will not ordinarily show named streams. The /R option is specifically useful for exposing them.
PowerShell can read a particular stream directly:
Get-Content -Path ".\example-file" -Stream Zone.Identifier
If the stream is present, this can display its contents, including a ZoneId entry. If the command does not return a Zone.Identifier stream, do not leap to a safety conclusion. The file may have come from a workflow that did not set MotW, may have been transferred through a location that did not preserve it, or may genuinely be local. The command answers a narrow question: whether that named NTFS stream is available on that particular copy of the file.
It is also wise to inspect the actual file, its publisher, and the download source rather than treating the stream as a complete forensic record. The core standardized example is the zone field itself; extra details sometimes associated with downloaded files should not be assumed to appear consistently across every application and version.
What MotW changes in real Windows use
MotW matters because Windows features and applications can use internet-origin context to apply more defensive defaults.
Office documents and macros
Office’s macro protections are one of the clearest examples. Microsoft states that macros in internet-sourced files are blocked by default. A document carrying MotW can therefore open with a warning that its macros have been blocked rather than simply running embedded code.
That is a major safeguard against phishing attachments and documents delivered through malicious downloads. Yet MotW is not the whole Office trust model. Trusted Locations, trusted publishers, and organizational policies can change the result. Conversely, the absence of a mark does not prove that a macro-enabled document deserves trust.
For home users, the right response to a blocked macro is usually not to immediately seek a way around it. Ask whether a macro is genuinely required, whether the sender independently confirmed the file, and whether the document arrived through an expected channel. For business users, unexpected macro-blocking often deserves escalation to IT or security staff rather than an improvised workaround.
PowerShell scripts
PowerShell provides another practical illustration. Under the RemoteSigned execution policy, downloaded scripts are blocked unless they are digitally signed. This makes origin information consequential for administrators and developers who routinely work with .ps1 files.
PowerShell includes Unblock-File, which removes the Zone.Identifier alternate stream:
Unblock-File -Path ".\example-script.ps1"
That command is sometimes presented as a fix for an inconvenient warning. It is more accurately a trust override. Microsoft explicitly advises reviewing both the file and its source before unblocking it. Removing the stream changes a local provenance signal; it does not inspect code, validate a publisher, establish that the script is benign, or undo any compromise already present.
A safer workflow is to obtain scripts from a known publisher or repository, check their contents when feasible, validate an expected signature where applicable, and keep an auditable record of why an exception was made—especially on managed systems.
MotW and SmartScreen are related—but not interchangeable
Windows users often group every “be careful” dialog under the SmartScreen label. That can create a dangerous misconception: that a MotW tag is a verdict from Microsoft, or that deleting it resolves all SmartScreen concerns.
SmartScreen is documented as a reputation-based system. Two core signals Microsoft identifies are publisher reputation and file-hash reputation. An application can trigger concern because it is new, uncommon, unsigned, or associated with an unknown or negative reputation. A warning is therefore not the same as a definitive malware finding, but neither is it a cosmetic nuisance to be dismissed automatically.
MotW and SmartScreen can both be relevant in the broader downloaded-file security path, yet they answer different questions:
- MotW records zone-of-origin context when it has been applied and preserved.
- SmartScreen evaluates reputation signals for downloaded files that users attempt to run.
- Antivirus and endpoint protection address another question: whether content matches detections or exhibits malicious behavior.
The available documentation does not establish that Zone.Identifier is the required deciding input for every SmartScreen warning. Users should therefore avoid reasoning such as, “I removed MotW, so SmartScreen should trust this file,” or, “SmartScreen warned me, so the MotW stream proves it is malicious.” Neither conclusion follows.
Archives are a weak point in the chain
Archives complicate the story because a downloaded .zip file may contain documents, scripts, or executables whose risk becomes apparent only after extraction. Windows Explorer has been shown to propagate an archive’s MotW to extracted content, an important behavior because it lets the origin context follow the payload rather than stop at the outer container.
This is security-relevant precisely because attackers have sought ways to place payloads inside nested containers in hopes that MotW will not reach the extracted file. The outcome can depend on the extraction tool and its version, and archive-handling defects have occurred. That makes “I downloaded a ZIP, then extracted it” a more meaningful event than it appears.
For users, the defensive rule is straightforward: do not assume extraction makes a file local, trusted, or detached from its original source. Keep your archiver updated, treat files inside unexpected archives with the same suspicion as direct downloads, and inspect executable files, scripts, and macro-enabled documents before opening them. In organizational environments, security teams should test the archivers and extraction workflows employees actually use, rather than assuming all tools preserve provenance identically.
Copying and sharing can strip useful context
Because MotW is stored as NTFS metadata, it is not guaranteed to survive copying, exporting, or moving a file through every storage medium and service. A file may lose the mark when transferred to a file system that does not preserve the NTFS alternate stream. It may also arrive without the mark if a participating download client was not involved in the first place.
That has two consequences.
First, a warning can disappear even though the file itself has not changed. The disappearance may reflect lost metadata, not newly earned trust.
Second, sending a file to someone else does not automatically transfer the same security context in every route. For teams that exchange installers, scripts, templates, or archives, provenance needs to be supported by stronger practices: verified publisher sources, signed code where practical, hashes obtained through an independent trusted channel, controlled software distribution, and endpoint protections.
A sensible response to Windows warnings
MotW is valuable because it adds friction at moments when people are most likely to make a rushed choice: opening a surprise document, enabling a macro, running a newly downloaded utility, or launching a script copied from a forum post.
Treat that friction as information, not an accusation and not an obstacle to bypass reflexively. Before choosing an unblock option or running Unblock-File, ask:
- Did I expect this file, and can I verify the sender or publisher independently?
- Does the file type make sense for the task—particularly if it is an executable, script, archive, or macro-enabled Office document?
- Is there an official distribution channel or a trusted publisher signature to compare?
- Why does this workflow need an exception rather than a safer, supported installation or deployment route?
For IT administrators, the broader lesson is that MotW is only one layer. Policies that preserve zone information can be useful, but they should sit alongside patching, application control, Microsoft Defender or other endpoint protection, macro controls, least privilege, and user reporting processes.
The hidden tag is real, and it is often helpful. Its limits are just as important. MotW can tell Windows that a file carries internet-origin context when the surrounding software, policy, and storage path preserve that context. It cannot guarantee that every downloaded file is labeled, and it cannot replace the judgment required before trusting code or documents from the internet.