MPP File Documentation

---

Technical details

Feature	Value
Full name	Microsoft Project Plan
File extension	.mpp
MIME type	application/vnd.ms-project
Format type	Proprietary binary project schedule
Container / base format	OLE2 Compound File Binary (Microsoft CFB)
Developer	Microsoft
Introduced	1990 (Microsoft Project for Windows); format revised through 2003/2007/2010+
Open standard	No — proprietary; [MS-PROJECT] documents it partially
Byte order	Little-endian (CFB)
Magic number (hex)	D0 CF 11 E0 A1 B1 1A E1
Native editor	Microsoft Project (Windows only; separate from Office/365)
Stores	Tasks, durations, dependencies, WBS, resources, costs, calendars, baselines, views
Macros	VBA, carried in the OLE2 container
Open exchange format	Project XML (MSPDI)
Related extensions	.mpt, .mpx, .mpd, .xml (MSPDI)
Specification	learn.microsoft.com — [MS-PROJECT]

What is an MPP file?

MPP is the native file format of Microsoft Project, the scheduling application Microsoft first shipped for Windows in 1990. A single .mpp holds an entire project plan: the task list with durations and start/finish dates, the dependencies that link tasks, the work breakdown structure, the resources assigned to work and their costs, the calendars that define working time, saved baselines, and the views that present all of it — most recognisably the Gantt chart. It is a live schedule rather than a static document; a manager updates progress and Project recalculates dates down the chain.

Two facts about MPP cause most of the confusion around it. First, Microsoft Project is sold separately from Microsoft Office and Microsoft 365: having Word and Excel does not let you open an .mpp. Second, MPP is a proprietary, version-sensitive binary format, and modern files are wrapped in the same OLE2 compound-document container as legacy .doc and .xls. This article looks at that container, how the schedule data is arranged inside it, and why the format behaves the way it does.

The OLE2 compound-document container

Since the Project 2000-era format, an .mpp is a Compound File Binary (CFB, also called OLE2 structured storage). CFB is a small file system living inside a single file: it organises content into named streams (the equivalent of files) grouped into storages (the equivalent of folders). Every CFB file begins with the same 8-byte signature.

Offset 0:  D0 CF 11 E0 A1 B1 1A E1   OLE2 / CFB header magic
           ...
           512-byte header: sector size, FAT layout, root directory sector
           FAT sectors     : the allocation table chaining stream sectors
           Directory stream: entries naming each storage and stream
           Mini-FAT + ministream: storage for streams under 4096 bytes

Because the container is generic, the signature D0 CF 11 E0 A1 B1 1A E1 does not by itself identify an MPP: a .doc, a .xls and an .msi all start the same way. What makes the file a Project plan is the set of named streams inside it. Project stores its schedule in internal streams whose byte layout Microsoft documents only partially, in the [MS-PROJECT] open specification. That partial documentation is exactly why third-party readers open MPP files with varying completeness: they can recover the task and resource tables reliably, but the precise formatting and view state less so.

The task table: the spine of the plan

The core of any plan is the task table. Each row is one task carrying, at minimum, a unique ID, a name, a duration, calculated start and finish dates, a percent-complete value, and its position in the outline. The outline is what makes a Project plan a hierarchy rather than a flat list: summary tasks contain sub-tasks, and a summary's dates and cost roll up from its children. This outline structure is the work breakdown structure (WBS), and each task carries a WBS code that encodes its place in the tree.

Durations are not stored as wall-clock time. A duration of "3 days" is interpreted against the task's calendar, which defines which days and hours count as working time. Change the calendar — add a holiday, switch to a 4-day week — and the finish dates move without any task field changing, because the engine recomputes them from the working-time definition. This is the difference between a schedule and a spreadsheet of dates.

Dependencies: the four link types and the scheduling engine

Tasks are connected by dependencies (task links), and it is the dependency network that lets Project recalculate the whole plan when one task slips. A link records a predecessor task, a successor task, a relationship type, and an optional lag.

Type	Meaning
FS (Finish-to-Start)	Successor starts after predecessor finishes (the default)
SS (Start-to-Start)	Successor starts when predecessor starts
FF (Finish-to-Finish)	Successor finishes when predecessor finishes
SF (Start-to-Finish)	Successor finishes when predecessor starts (rare)

A lag adds delay (or, as negative lead, overlap) to a link. From these links and each task's constraints, Project runs a critical-path calculation: it finds the longest dependent chain through the network, which determines the earliest possible finish for the whole project. Tasks on that chain have zero slack; slipping any of them slips the project end date. This computed critical path is stored and recalculated whenever the plan changes, and it is what a Gantt view highlights.

Resources, assignments and baselines

A plan carries a resource table alongside the task table: the people, equipment or materials that do the work, each with a cost rate and an availability calendar. An assignment joins a resource to a task and records how much work that resource does on it. Assignments are why a task can have a duration in days but a separate work value in hours, and why over-allocating one person across two concurrent tasks produces a resource conflict the plan can flag.

A baseline is a saved snapshot of the plan's dates, durations, work and cost at a point in time. Project can store multiple baselines. Their purpose is variance tracking: once work starts, the current schedule drifts from the baseline, and the difference (a task finishing later than baselined, a cost exceeding the baselined cost) is the schedule and cost variance a manager reports. The baseline fields live in the same task/resource streams as the live values, stored in parallel.

Views: why the same plan looks different in different tools

The data in an MPP is separate from the views that display it. The Gantt chart, the tracking view, the resource sheet, the network diagram — these are presentations layered over one underlying task/resource model, along with the filters, groupings, formatting and column layouts a user has set. A Gantt bar is not stored as a picture; it is drawn on demand from a task's start, finish and percent-complete against a timescale.

This separation explains a common surprise: open the same .mpp in Microsoft Project and in a free viewer and the schedule data matches, but the formatting and custom views may not carry over, because reproducing Project's exact view state from the partially documented streams is the hardest part for third-party readers. It also explains why exporting to Excel or CSV keeps the task table but loses the Gantt entirely — the export takes the data model, not the view.

MPP versus Project XML (MSPDI)

Because the binary MPP is proprietary and version-sensitive, Microsoft provides an open, documented text alternative: Project XML, sometimes called MSPDI (Microsoft Project Data Interchange). Saving a plan as XML writes the same tasks, links, resources and assignments as element-based text that any tool can parse without reverse-engineering the CFB streams. When a newer Project file will not open in an older Project, or when a plan must move to a non-Microsoft scheduler, exporting to Project XML is the reliable path: it is the format designed for interchange, whereas MPP is designed for Project's own storage.

The version sensitivity is real. A plan saved by a newer Microsoft Project may refuse to open in an older one, because the older engine does not understand the newer stream schema. The remedy is to have the sender save down to your Project version, or to exchange the plan as Project XML, which is far more portable across versions and tools.

Macros in the OLE2 container

An MPP is passive schedule data, but its OLE2 container can also carry VBA macros, because Microsoft Project supports Visual Basic for Applications just as Word and Excel do. That makes an .mpp from an unknown sender the same class of risk as any other macro-capable Office document: the schedule itself cannot run, but embedded VBA can, if you enable it. Treat macros in a received plan as untrusted and leave them disabled unless you trust the source. Read-only viewers such as MOOS Project Viewer do not execute Project macros, which makes them the safe way to inspect an unfamiliar plan. Absent macros, the only practical concern with an MPP is version compatibility, not malware.

References

• Microsoft — [MS-PROJECT] file format open specification
• Microsoft — Project (product page)
• ProjectLibre — free open-source MS Project alternative

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.