APPX File Documentation

Summary

An .appx file is a Windows 8 App Package, the installation package format Microsoft introduced in 2012 for Universal Windows Platform apps and later packaged desktop apps. It is a ZIP archive following the Open Packaging Conventions, holding the app’s binaries plus an AppxManifest.xml, a per-block hash map (AppxBlockMap.xml) and a digital signature (AppxSignature.p7x). Its MIME type is application/appx. Since 2018 its successor is MSIX, which uses the same container. APPX is Windows-only.

Technical details

FeatureValue
Full nameWindows 8 App Package (AppX)
File extension.appx
MIME typeapplication/appx
Format typeWindows application package (binary)
Container / base formatZIP, following the Open Packaging Conventions (OPC)
DeveloperMicrosoft
Introduced2012 (Windows 8)
SuccessorMSIX (2018), same OPC/ZIP container
Open standardNo
PlatformWindows-only (Windows 8/10/11)
Byte orderLittle-endian (ZIP structures)
Magic number (hex)50 4B 03 04 (ASCII PK, ZIP local file header)
Manifest partAppxManifest.xml (identity, capabilities, entry points)
Integrity partAppxBlockMap.xml (per-block SHA-256 hashes)
Signature partAppxSignature.p7x (PKCS#7 code signature)
Content-type part[Content_Types].xml
SigningMandatory — unsigned/untrusted packages are refused
Install locationSandboxed, per-user; clean uninstall
Bundle variants.appxbundle / .msixbundle (multi-architecture)
Related extensions.msix, .appxbundle, .msixbundle, .appinstaller, .xap
Specificationlearn.microsoft.com/windows/msix/
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes, ASCII PK — the standard ZIP local file header. An APPX is an Open Packaging Conventions (OPC) ZIP, the same container family as DOCX and XLSX, so it begins exactly like a plain ZIP. It is identified not by the header but by three mandatory parts inside: AppxManifest.xml, AppxBlockMap.xml and AppxSignature.p7x. The newer MSIX package uses the same 50 4B 03 04 start and the same layout.

What is an APPX file?

APPX is the Windows 8 App Package format, the application-installation package Microsoft introduced with Windows 8 in 2012. It was created to distribute and install Universal Windows Platform (UWP) apps from the Microsoft Store, and later also packaged Win32 desktop apps. An .appx file bundles an app’s executables, libraries, images and resources together with the metadata Windows needs to verify, install, sandbox and cleanly uninstall it. Since 2018 Microsoft has positioned MSIX as the successor; MSIX uses the same underlying container and tooling, so much of what follows applies to .msix as well.

Technically an APPX is a ZIP archive that follows the Open Packaging Conventions (OPC), the same container standard used by Office’s DOCX and XLSX. That means it starts with the ZIP local file header 50 4B 03 04 and can be opened by any ZIP tool for inspection. What makes it a Windows app package rather than a plain ZIP is a set of mandatory parts inside — a manifest, a block map and a signature — described below. APPX runs only on Windows; the old database claim that it works across HP-UX, AIX and Linux is false.

The OPC package layout

Unzipping an APPX reveals the app’s files plus three OPC housekeeping parts and three package-specific ones. Every part is named like a path from the archive root:

/                       (ZIP root)
├─ AppxManifest.xml      app identity, capabilities, entry points, targets
├─ AppxBlockMap.xml      per-file, per-block SHA-256 hashes
├─ AppxSignature.p7x     PKCS#7 digital signature over the block map
├─ [Content_Types].xml   OPC content-type map for every part
├─ AppxMetadata/
│   └─ CodeIntegrity.cat  optional catalog for kernel-mode components
├─ Assets/               logos, tile and splash images
└─ (app binaries)        .exe, .dll, .winmd, resources

The [Content_Types].xml part is the OPC manifest that declares the content type of every part, the same role it plays in any OPC package. The three Appx* parts are what Windows’ deployment engine (the AppX Deployment Service) reads to decide whether the package may be installed at all. Because it is an ordinary ZIP underneath, you can rename a copy to .zip or open it with 7-Zip to read AppxManifest.xml and extract assets without installing anything.

AppxManifest.xml: identity, capabilities and entry points

The manifest is the heart of the package. It declares the app’s identity — a name, publisher and version — and this identity is bound to the signature: the publisher string in the manifest must match the subject of the signing certificate, or installation is rejected. The manifest also declares the app’s capabilities, which are the permissions the app requests (network access, the file system, the camera, location and so on); Windows surfaces these and enforces them at runtime through the app sandbox.

<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10">
  <Identity Name="Contoso.MyApp"
            Publisher="CN=Contoso Ltd, O=Contoso, C=US"
            Version="1.4.2.0"
            ProcessorArchitecture="x64"/>
  <Properties>
    <DisplayName>My App</DisplayName>
    <PublisherDisplayName>Contoso</PublisherDisplayName>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop"
                        MinVersion="10.0.17763.0"
                        MaxVersionTested="10.0.22621.0"/>
  </Dependencies>
  <Capabilities>
    <Capability Name="internetClient"/>
  </Capabilities>
  <Applications>
    <Application Id="App" Executable="MyApp.exe" EntryPoint="MyApp.App">
      <uap:VisualElements DisplayName="My App" .../>
    </Application>
  </Applications>
</Package>

The <Identity> element’s ProcessorArchitecture is why a single-architecture APPX targets one CPU (x86, x64 or ARM), and why bundles exist to cover several at once. <TargetDeviceFamily> pins the minimum Windows build the app supports. Each <Application> names the executable and its entry point, and its visual elements supply the tile and display name Windows shows. A reader that wants to know what an APPX actually does starts here.

AppxBlockMap.xml: block hashing for integrity and delta updates

The block map is what makes an APPX tamper-evident and cheap to update. Rather than hashing each file once, Windows splits every file in the package into 64 KB blocks and records a SHA-256 hash of each block. The block map lists, per file, its uncompressed size and the ordered hashes of its blocks.

<BlockMap xmlns="http://schemas.microsoft.com/appx/2010/blockmap"
          HashMethod="http://www.w3.org/2001/04/xmlenc#sha256">
  <File Name="MyApp.exe" Size="204800" LfhSize="49">
    <Block Hash="Base64-SHA256-of-block-1..."/>
    <Block Hash="Base64-SHA256-of-block-2..."/>
  </File>
</BlockMap>

Two consequences follow. First, integrity: at install time and while streaming, Windows can hash each 64 KB block as it reads it and compare against the block map, so any corruption or tampering is caught at block granularity rather than only after downloading a whole file. Second, differential updates: when a new version changes only part of a file, the blocks whose hashes are unchanged do not need re-downloading, so an update transfers only the changed blocks. The block map is also the exact data the signature protects, which links these two parts together.

AppxSignature.p7x and the trust requirement

APPX signing is mandatory, and this is the format’s defining security property. AppxSignature.p7x is a PKCS#7 (Authenticode-style) signature. It does not sign every file individually; it signs the AppxBlockMap.xml. Because the block map in turn contains the hashes of every block of every file (including the manifest), signing the block map transitively protects the entire package: change any byte of any file and its block hash changes, which changes the block map, which invalidates the signature.

The .p7x stream begins with a 4-byte marker APPX (50 4B 43 58 in the P7X wrapper) followed by the PKCS#7 blob. At install, Windows verifies that the signature is valid, that it covers the block map, and that the signing certificate chains to a certificate the machine trusts. Store apps are signed by Microsoft and trusted automatically. A package from outside the Store is only installable if sideloading is enabled and its signing certificate has been placed in the machine’s Trusted People or Trusted Root store. This is why the most common APPX error is “app package is not signed” or “not trusted”: the file is fine, but its certificate is not trusted by that PC.

A single APPX targets one processor architecture. To ship one file that covers several, Microsoft defines the bundle: an .appxbundle (or the MSIX-era .msixbundle) is itself an OPC ZIP that contains multiple architecture-specific APPX/MSIX packages plus an AppxBundleManifest.xml, and Windows installs the one matching the device. An .appinstaller file is a small XML manifest that points at a package and enables automatic updates. MSIX, the 2018 successor, keeps the same OPC container, the same block map and the same signing model, but broadens support to traditional Win32 desktop apps alongside UWP; new packaging is done as MSIX while APPX remains installable for backward compatibility. The dead Windows Phone predecessor was .xap, a Silverlight package unrelated to the current model.

Installing an APPX and inspecting one safely

On Windows 10 and 11, double-clicking a signed, trusted .appx opens the built-in App Installer, which shows the app’s identity and an Install button. From a shell, Add-AppxPackage -Path app.appx installs it for the current user, and Add-AppxProvisionedPackage installs it for all users; both require sideloading to be permitted and the certificate to be trusted. There is no conversion to .exe or .apk — those are different install models for a different runtime and, in APK’s case, a different operating system.

Because an APPX is a real installer that runs code, treat it with the same care as any software install, with one structural advantage: an unsigned or untrusted package simply will not install, and an installed package runs sandboxed and uninstalls cleanly. The genuine risk is people disabling those protections to sideload — being told to enable developer mode and drop a stranger’s certificate into Trusted Root is exactly how a malicious package gets in. Since the file is an OPC ZIP, you can inspect it before ever installing: open it with 7-Zip, read AppxManifest.xml to see what capabilities the app demands and who the declared publisher is, and check who signed it. Only sideload packages from a source you trust.

References