MANIFEST File Documentation

Summary

A .manifest file is a Windows application manifest: an XML document that tells the operating system how to run a program — which shared-library versions it needs, whether it requires administrator rights (UAC), and its DPI and compatibility settings. It is plain UTF-8 text with the MIME type application/xml, so you can read it in Notepad or Notepad++. You don't run it; Windows reads it automatically when launching the matching .exe. Editing one is a developer task.

Technical details

FeatureValue
Full nameWindows Application Manifest (side-by-side assembly manifest)
File extension.manifest
MIME typeapplication/xml
Format typeXML metadata file (UTF-8 text)
DeveloperMicrosoft
IntroducedWindows XP (2001); UAC manifests since Windows Vista (2007)
Open standardNo — Microsoft schema (well-formed XML)
Magic numberNone — XML text, typically starts <?xml or <assembly
Root element<assembly> in namespace urn:schemas-microsoft-com:asm.v1
DeliveryEmbedded in the .exe/.dll as a resource, or external App.exe.manifest
Declares (UAC)requestedExecutionLevel: asInvoker / highestAvailable / requireAdministrator
Declares (display)DPI awareness, common-controls visual styles
Declares (deps)Dependent assemblies (e.g. Common Controls v6, VC++ runtime)
Declares (compat)supportedOS GUIDs, long-path awareness
ToolingVisual Studio, mt.exe (manifest tool)
Same-name othersJava MANIFEST.MF (text), PWA web app manifest (JSON)
Related extensions.xml, .exe, .dll, .config, .application
CategorySystem / configuration
Specification URLlearn.microsoft.com/windows/win32/sbscs/application-manifests
Structure at a glance

A Windows .manifest is XML text with no binary signature. Most begin with the XML declaration <?xml version="1.0" encoding="UTF-8" standalone="yes"?> followed by an <assembly> root in the namespace urn:schemas-microsoft-com:asm.v1 with a manifestVersion="1.0" attribute; some omit the declaration and open directly with <assembly>. Inside, the load-bearing elements are <trustInfo> → <requestedExecutionLevel> (the UAC level), <dependency> (shared assemblies the app needs), and <application> → <windowsSettings> (DPI awareness and supported-OS GUIDs).

What is a .manifest file?

On Windows, a .manifest file is an XML document that describes how an executable should be loaded and run. Microsoft calls it an application manifest or side-by-side (SxS) assembly manifest. It was introduced with Windows XP in 2001 to solve "DLL hell": a manifest lets a program declare exactly which versions of shared components it depends on, so Windows binds the right ones instead of whatever happens to be installed globally. Since Windows Vista (2007), manifests also carry the User Account Control (UAC) privilege level, which is why a program does or does not prompt for administrator rights when you launch it.

A manifest is developer-facing metadata, not user content. It is plain UTF-8 XML, so it opens in any text editor, but you never "run" it — Windows reads it automatically when it launches the matching program. Most users meet a loose .manifest file only by finding a MyApp.exe.manifest in a program's folder and wondering what it is. The sections below cover the XML structure, the UAC level and the DPI/compatibility settings a manifest carries, how it is embedded into or shipped beside an executable, and why the same word is reused by unrelated formats. The authoritative reference is Microsoft's application-manifest documentation.

The XML structure

A manifest is a small, well-formed XML tree. It usually opens with an XML declaration, then an <assembly> root element in the Microsoft assembly namespace, and inside it a handful of elements that each control one aspect of how the program loads.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="MyCompany.MyApp"
                    version="1.0.0.0" processorArchitecture="amd64"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security><requestedPrivileges>
      <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
    </requestedPrivileges></security>
  </trustInfo>
  <dependency><dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0" processorArchitecture="amd64"
        publicKeyToken="6595b64144ccf1df" language="*"/>
  </dependentAssembly></dependency>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>
</assembly>

<assemblyIdentity> names this application or assembly with a name, version and processor architecture. <dependency> lists shared components the app needs — the example pulls in Common Controls version 6, which is what gives an app the modern themed buttons and dialogs instead of the flat Windows 95 look. <trustInfo> carries the UAC level, and <application> → <windowsSettings> holds display and compatibility settings. Note that different sub-trees use different namespace versions (asm.v1, asm.v3), which is normal for manifests.

The requestedExecutionLevel and UAC

The single most consequential field is requestedExecutionLevel inside <trustInfo>. It declares the privilege the program asks Windows for at launch, and it takes one of three values. asInvoker runs the app with the same rights as whatever started it, with no elevation prompt — the correct default for most programs. highestAvailable requests the highest privileges the user can grant. requireAdministrator forces an elevation prompt every time, and the program will not start without administrator rights. This one attribute is why some installers and system tools always show the UAC consent dialog while ordinary apps do not: Windows reads the level from the manifest before the program's own code runs.

DPI awareness and OS compatibility

Beyond privileges, a manifest tunes how the program renders and which Windows versions it targets. The dpiAware (and newer dpiAwareness) setting tells Windows the app scales itself for high-resolution displays; without it, Windows bitmap-stretches the app on a 4K monitor, producing the blurry text people often try to fix. The <compatibility> section lists supportedOS GUIDs, one per Windows release the app has been tested against, which affects how certain compatibility shims behave. A longPathAware setting opts the app into path lengths beyond the old 260-character MAX_PATH limit. All of these are declarative: the app doesn't call an API to request them, it states them in the manifest and Windows applies them at load time.

Embedded versus external manifests

A manifest reaches Windows one of two ways. It can be embedded as a resource inside the .exe or .dll itself (resource type RT_MANIFEST, ID 1), which is the usual production form — there is no loose file, and the manifest travels inside the binary. Or it can ship as an external file in the same folder, named after the program: MyApp.exe.manifest. Windows checks for the external file and uses it if present. Developers embed a manifest with Visual Studio's project settings or with the manifest tool mt.exe (mt.exe -manifest App.manifest -outputresource:App.exe;1). This is why finding a loose .manifest next to a program matters: some apps rely on that external file and fail to launch if you delete it.

The same name, different formats

"Manifest" is reused across ecosystems, and the bare .manifest extension is only the Windows meaning. Inside a Java .jar archive, META-INF/MANIFEST.MF is a plain-text (not XML) manifest listing the main class and JAR attributes. Progressive web apps use a JSON web app manifest (usually manifest.json or manifest.webmanifest) describing the installable app's name and icons. Build tools and game engines write asset or cache manifests as text or JSON listing bundled files. These share the word but not the format — if a file called "manifest" is JSON or a plain key-value list rather than an <assembly> XML tree, it is one of these other kinds, not a Windows application manifest.

Frequently asked questions

How do I open a .manifest file?

It is XML text, so open it in Notepad, Notepad++ or VS Code to read it. You don't normally run it; Windows reads it automatically when launching the related .exe. You can also rename a copy to .xml to view it in an XML editor.

Can I delete a .manifest file?

If it sits next to a program as MyApp.exe.manifest, no — some apps won't start without it. Build or temporary manifests inside a developer's project folder are usually safe to remove. When in doubt, keep it.

What is the difference between a .manifest file and MANIFEST.MF?

Different things that share the name. A Windows .manifest is XML describing how to run an app; MANIFEST.MF inside a Java .jar is a plain-text file listing the JAR's main class and attributes. They are not interchangeable.

References