OXPS File Documentation

Summary

An OXPS file is a fixed-layout document in the OpenXPS (Open XML Paper Specification) format, Microsoft’s ECMA-standardised page format and a close relative of PDF. It is a ZIP package holding XML page markup, fonts and images, produced by the “Microsoft XPS Document Writer” virtual printer on Windows 8 and later. Its extension is .oxps and its MIME type is application/oxps. On Windows 10/11 open it by adding the optional XPS Viewer feature.

Technical details

FeatureValue
Full nameOpenXPS Document (Open XML Paper Specification)
File extension.oxps
MIME typeapplication/oxps
Format typeFixed-layout document package (paginated, non-reflowable)
Container / base formatZIP archive following the Open Packaging Conventions (OPC)
Page markupXML — FixedPage elements (.fpage parts)
DeveloperMicrosoft
Standardised byEcma International
Standard / specECMA-388 (1st edition, June 2009)
Introduced2009; default XPS flavour since Windows 8 (2012)
Open standardYes — published as ECMA-388
Magic number (hex)50 4B 03 04 (ZIP local file header, “PK”)
Byte orderLittle-endian (ZIP structures)
Namespacehttp://schemas.openxps.org/oxps/v1.0
Package rootFixedDocumentSequence.fdseq
Embedded resourcesObfuscatedType fonts, raster images, colour profiles
EditableNo — fixed page layout, like PDF
Digital signaturesSupported (OPC digital-signature parts)
PredecessorXPS (Microsoft’s 2006 original, .xps)
Related extensions.xps, .pdf, .zip
Specificationecma-international.org/publications-and-standards/standards/ecma-388
File signature (magic bytes)
50 4B 03 04

Offset 0, 4 bytes. This is the ZIP local file header (P K followed by 03 04), because an OXPS file is a ZIP package, not a distinct binary format. A file manager that reads the signature alone sees only a ZIP archive. What marks it as OpenXPS rather than a plain .zip or a .docx is the internal part layout: a [Content_Types].xml map, a FixedDocumentSequence.fdseq at the root, and page parts in the http://schemas.openxps.org/oxps/v1.0 namespace. Rename an .oxps to .zip and any archiver will list those parts.

What is an OXPS file?

OXPS is short for OpenXPS, the Open XML Paper Specification, a fixed-layout page format published by Ecma International as ECMA-388 in June 2009. Like PDF, it stores a finished, print-ready document: vector graphics, embedded fonts and text placed at exact coordinates, page by page, with no reflow. An .oxps file records how a document looks when printed, not an editable source you can rework into paragraphs.

Structurally an OXPS file is not a single binary blob. It is a ZIP archive that follows the Open Packaging Conventions (OPC), the same packaging model behind DOCX and XLSX. Inside the ZIP are XML parts describing each page, plus the fonts and images those pages reference. OpenXPS is the Ecma-standardised successor to Microsoft’s original 2006 XPS format; Windows 8 and later produce .oxps where Windows 7 produced .xps. Its MIME type is application/oxps. Everything below is about how that OPC package is laid out, part by part.

The OPC ZIP package and [Content_Types].xml

Because OpenXPS is built on the Open Packaging Conventions, the outer file is an ordinary ZIP archive: it opens byte-for-byte with any ZIP tool, and its first four bytes are the ZIP local file header 50 4B 03 04. Rename an .oxps to .zip, extract it, and you get a folder tree of XML and resource files rather than one opaque document.

Every OPC package must contain a part called [Content_Types].xml at the root of the archive. It maps file name extensions and specific part names to MIME content types, so a reader knows that .fpage parts are page markup, .fdoc parts are documents, .odttf parts are obfuscated fonts, and so on. Relationships between parts are declared in _rels/.rels and per-part .rels files, exactly as in a DOCX. The package is therefore self-describing: a parser reads [Content_Types].xml first, then follows relationships to find the document root.

example.oxps  (a ZIP / OPC package)
 ├─ [Content_Types].xml            content-type map for every part
 ├─ _rels/.rels                    package-level relationships → the .fdseq root
 ├─ FixedDocumentSequence.fdseq    root: lists the documents in the package
 ├─ Documents/
 │   └─ 1/
 │       ├─ FixedDocument.fdoc     ordered list of this document's pages
 │       ├─ Pages/
 │       │   ├─ 1.fpage            XML markup of page 1 (Glyphs, Path, ...)
 │       │   └─ 2.fpage            XML markup of page 2
 │       └─ _rels/                 page → font/image relationships
 └─ Resources/
     ├─ Fonts/                     embedded (often obfuscated) fonts
     └─ Images/                    embedded raster images (PNG/JPEG/TIFF)

FixedDocumentSequence: the .fdseq root part

The entry point of the content is a part called FixedDocumentSequence.fdseq. ECMA-388 recommends but does not strictly mandate that extension for the root; the reader locates it through the package relationship of type .../fixedrepresentation rather than by guessing the file name. The .fdseq is a short XML file listing one or more documents in reading order, each pointed at by a source reference.

<FixedDocumentSequence xmlns="http://schemas.openxps.org/oxps/v1.0">
  <DocumentReference Source="/Documents/1/FixedDocument.fdoc" />
</FixedDocumentSequence>

This two-level design, a sequence of documents each containing a sequence of pages, is why a single OXPS package can bundle several logical documents (for example a cover letter and an invoice) that a viewer presents as one continuous file. The sequence file holds no visual content of its own; it is pure navigation.

FixedDocument and FixedPage: the page tree

Each DocumentReference points at a FixedDocument part (conventionally .fdoc), whose only job is to list the pages of that document in order through PageContent elements. Every PageContent references one FixedPage part (.fpage), and it is the FixedPage that actually paints ink on the page.

<FixedDocument xmlns="http://schemas.openxps.org/oxps/v1.0">
  <PageContent Source="Pages/1.fpage" />
  <PageContent Source="Pages/2.fpage" />
</FixedDocument>

A FixedPage declares its Width and Height in units of 1/96 inch (the XPS device-independent pixel), then lists drawing elements. The two workhorse elements are Glyphs, which places a run of text at an exact origin with a named font and per-glyph advance widths, and Path, which draws filled or stroked vector geometry. Because text is emitted as positioned glyph runs with explicit indices and offsets, layout is pixel-exact and independent of the reader’s installed fonts, but the reading order and word boundaries are not guaranteed, which is why text extraction from OpenXPS can be imperfect.

<FixedPage Width="816" Height="1056" xml:lang="en-US"
           xmlns="http://schemas.openxps.org/oxps/v1.0">
  <Glyphs Fill="#ff000000"
          FontUri="/Resources/Fonts/A1B2C3D4-....odttf"
          FontRenderingEmSize="16"
          OriginX="96" OriginY="120"
          UnicodeString="Invoice 2026-0473"
          Indices="..." />
  <Path Fill="#ffe0e0e0" Data="M 96,140 L 720,140 L 720,142 L 96,142 Z" />
</FixedPage>

Embedded fonts and ODTTF obfuscation

To render exactly the same on any machine, an OXPS package embeds the fonts its pages use, stored under Resources/Fonts/ and referenced by the FontUri attribute of each Glyphs element. Many of these fonts are stored as obfuscated font parts, given the content type application/vnd.ms-package.obfuscated-opentype and usually the .odttf extension.

Obfuscation here is not encryption and not a security feature; it is a licensing convention shared with DOCX. The first 32 bytes of the OpenType font file are XORed with the 16 bytes of the GUID that forms the part’s file name (applied twice across the 32 bytes). A reader reverses the XOR using that GUID to recover a normal OpenType font before handing it to the rasteriser. The intent is only to stop a casual user from double-clicking the extracted font and installing it system-wide, since the font may be licensed for embedding but not for general use.

OXPS versus XPS: the namespace difference

OpenXPS and the older XPS are almost the same design, but they are not byte-compatible, and the difference is mostly in the XML namespace and a few part conventions. Microsoft’s 2006 XPS used the namespace http://schemas.microsoft.com/xps/2005/06; ECMA-388 OpenXPS uses http://schemas.openxps.org/oxps/v1.0. A reader keyed to one namespace will reject the other, which is exactly why Windows 7’s XPS Viewer cannot open an .oxps even though the internal model is nearly identical.

The XPS Viewer that shipped with Windows 8 and later reads both. On Windows 10 (since version 1803, April 2018) and Windows 11 that viewer is no longer preinstalled and must be added under Settings → Apps → Optional features → XPS Viewer, which is the single most common reason a freshly received .oxps appears to open nothing. Microsoft’s command-line XpsConverter tool translates between the two namespaces for legacy applications that accept only .xps.

How OpenXPS files are created on Windows

Users almost never create an OXPS file deliberately. The file appears when someone prints to the “Microsoft XPS Document Writer”, a virtual printer Windows 8, 10 and 11 install by default. Choosing it in the print dialog produces an .oxps instead of paper output, which is why a stray OXPS often means a physical printer or “Microsoft Print to PDF” was intended but the XPS writer was selected. The format is otherwise a print-pipeline artefact: Windows’ print spooler uses the XPS document model internally, so writing the spool stream to a file yields OpenXPS naturally.

Deep questions about the OpenXPS format

Why does an OXPS file start with the same bytes as a ZIP or DOCX?

Because all three are OPC packages, and OPC is defined on top of ZIP. The first four bytes are always the ZIP local file header 50 4B 03 04. The format is distinguished not by a magic number but by what is inside: the [Content_Types].xml content types and the FixedDocumentSequence.fdseq root in the OpenXPS namespace.

Can text be pulled cleanly out of an OXPS file?

Only approximately. OpenXPS stores each line as Glyphs runs positioned by coordinate, with a UnicodeString and glyph indices, but it does not record paragraph structure or reliable reading order. An extractor recovers the characters, yet spaces, column order and line breaks have to be inferred from geometry, so multi-column pages often come out jumbled.

References