Microsoft Portable Executable MIME Type

What does application/vnd.microsoft.portable-executable mean?

The application/vnd.microsoft.portable-executable media type identifies Microsoft's Portable Executable (PE) format. Windows uses PE image files for programs and dynamically loaded libraries. The IANA registration lists .exe and .dll as its extensions and describes the content as uncompressed binary data.¹

"Portable" does not mean that one file runs on every operating system or processor. It means the container is not tied to one CPU architecture. A field in the PE header identifies the intended machine, such as x86, x64, or Arm64, and the image can run only on a compatible machine or emulator.²

An .exe normally has an entry point that Windows can launch as a process. A .dll exposes code or resources for another program to load. Both can use the same PE container, which is why one MIME type covers both extensions.

How can you identify a PE file?

IANA records MZ, or hexadecimal 4D 5A, as the magic number.¹ Those two bytes begin the legacy DOS header at offset zero. They are a useful first check, but they are not sufficient by themselves because older DOS executables also begin with MZ.

A PE-aware tool follows the four-byte pointer at file offset 0x3C. That pointer leads to the four-byte signature 50 45 00 00, commonly written as PE\0\0. Microsoft specifies this structure:²

Do not identify a file from its extension alone. A renamed document can end in .exe, and a PE image can use another extension. Inspect both signatures and validate the header offsets and bounds before trusting the result.

History and registration

Microsoft developed PE for the Windows NT line. Windows NT 3.1, announced in 1993, was the first public Windows NT release, so 1993 is the practical starting date for PE as a deployed Windows format.³ PE adapted concepts from the Common Object File Format (COFF) while adding the image information needed by the Windows loader.

IANA registered application/vnd.microsoft.portable-executable on April 23, 2015. The registration has no required or optional parameters and names no deprecated aliases.¹ You may encounter generic values such as application/octet-stream when a server does not recognize a binary. That value says only "arbitrary binary data" and is not an alternate version of the registered PE media type.

How to open or inspect a PE file

Running and inspecting are different operations. On a compatible Windows system, opening a trusted .exe launches it, while a .dll is normally loaded by another program. Web browsers do not render PE contents as a document or media format. They treat the file as a download.

For inspection without execution:

• File Explorer can show version information and, when present, a Digital Signatures tab.
• PowerShell provides Get-AuthenticodeSignature to report an embedded or catalog signature and its validation status.⁴
• Visual Studio DUMPBIN can display PE headers, imported DLLs, exported symbols, and section information.
• Sysinternals Sigcheck reports hashes, version fields, timestamps, and certificate-chain details.⁵

Support in Poly

Poly stores, syncs, shares, versions, and downloads PE files. Its MIME model explicitly recognizes application/vnd.microsoft.portable-executable, maps .exe to that type, and classifies it as an executable.

Support stops at file management and basic properties:

• PE files are searchable by filename, but Poly does not index machine code, strings, imports, exports, resources, or embedded manifests.
• Poly does not generate a thumbnail or provide an in-app PE viewer.
• The Poly agent cannot read or reason about the binary's internal program behavior.
• To inspect one, download it and use a trusted static-analysis tool. Poly never needs to execute the file.

This is intentionally different from Poly's handling of text, images, audio, video, PDFs, and office documents, where format-specific extraction can power previews and content search.

Can you convert a PE file?

A PE file is compiled program code, not a document or media asset, so there is no general conversion to PDF, text, or an image. Choose an extraction or analysis task instead:

• Export version fields, headers, imports, or symbols as text with a PE inspection tool.
• Extract icons, manifests, or other embedded resources when you have permission.
• Use a disassembler or decompiler to study code. The result is an analysis, not a reversible conversion to the original source.
• Rebuild for a different operating system or CPU from source code. Changing the extension or editing the machine field does not port a program.

The same warning applies to converting .dll to .exe. A DLL may have no suitable process entry point or user interface, and its code may depend on a specific host. The two extensions describe different roles, even though both files use PE.

Signatures, checksums, and trust

PE supports both an image checksum and Authenticode signatures. They solve different problems. The checksum helps Windows validate certain images at load time, but it is not a cryptographic statement of authorship. Authenticode associates a publisher's certificate with a cryptographic digest so changes can be detected.²

A valid signature is useful evidence that the file has not changed since signing and that the certificate chains to a trusted authority. It is not proof that the software is safe or appropriate to run. An unsigned file is not automatically malicious either. Treat the signature as one input alongside the download source, file hash, reputation, expected version, and security scan.

PE itself provides no confidentiality. Strings, resources, metadata, and parts of the program can be visible to inspection tools even when the file is signed.¹