.PRPROJ File Format – Document and objects

The gzip wrapper

The file is a single gzip member (RFC 1952) holding one XML document. Premiere writes a fixed 10-byte header with no optional fields, a raw deflate stream compressed at zlib’s default level 6, and the usual 8-byte trailer.

A project re-compressed by another tool may carry the optional gzip fields; a reader should parse the flags rather than assume 10 bytes.

The XML

The decompressed document is UTF-8. Premiere’s writer is uniform:

• The prolog is exactly <?xml version="1.0" encoding="UTF-8" ?> (note the space before ?>) and a line feed.
• Lines end with LF and nesting is indented with tabs. Empty elements are self-closing.
• Line breaks inside a text value are written as character references, 
 and 
, so every raw line feed in the file is formatting. Attribute values also escape tabs as 	.
• The root element is followed by two line feeds.
• There are no comments, processing instructions or CDATA sections, and no mixed content: an element holds either text or child elements.

PremiereData and the object table

The root element is PremiereData with a Version attribute (3 in current projects). Its children form a flat table of objects. The first child is a reference to the project object; everything else is an object definition:

<PremiereData Version="3">
	<Project ObjectRef="1"/>
	<Project ObjectID="1" ClassID="62ad66dd-0dcd-42da-a660-6d8fbde94876" Version="45">
		…
		<RootProjectItem ObjectURef="…"/>
		<ProjectSettings ObjectRef="3"/>
		…
	</Project>
	<RootProjectItem ObjectUID="…" ClassID="1c307a89-9318-47d7-a583-bf2553736543" Version="1">
	…
</PremiereData>

Premiere writes the identifier first, then ClassID, then Version. A reference element has no content; its name says what role the referenced object plays, as in <ProjectSettings ObjectRef="3"/>.

A few objects contain nested definitions with their own ObjectIDs, such as the project panel’s view state and its column classes. IDs inside those belong to the nested scope and do not point into the top-level table.

Class layers

An object definition is built from layers, one for each class it derives from, nested as child elements that each carry their own Version. A bin, for example, is a BinProjectItem containing a ProjectItem layer (with a Node, its Properties and the Name) and a ProjectItemContainer layer (with the Items it holds). Generic settings live in Node/Properties as leaf elements whose names are dotted keys, such as MZ.Project.GUID or Column.PropertyText.Label.

Binary payloads

Binary data, such as caption and graphics text, Lumetri settings and other effect state, is stored as base64 text in a leaf element. A given payload is stored once: the first element that needs it carries the base64 text and a BinaryHash attribute, and every further copy is an empty element with the same BinaryHash. Styled text payloads (captions and Essential Graphics source text) are FlatBuffers that start with the bytes 44 33 22 11. Most other payloads are not publicly decoded.

An empty project

Premiere writes about 40 objects for a new, empty project. Nine of them hold state it cannot rebuild; it restores the rest from its defaults when it opens a project that lacks them.

What the file does not hold

• The media. Clips refer to files by path (Media/FilePath).
• XMP metadata set on an item: Premiere writes it into the media file, not the project.
• Node IDs of project items are reassigned by Premiere on every load, from 1000000 in depth-first order; stored IDs are not authoritative.
• Selection, playhead positions and other live application state.