If you have used Windows for a while, you have probably opened a .xps or .oxps file at some point, usually by accident, after clicking "Print" and choosing the wrong virtual printer. XPS stands for XML Paper Specification: Microsoft's late-2000s alternative to PDF for fixed-layout documents. It still exists in Windows. It is also, by any measure, on its way out. This article looks at what XPS is, why it never displaced PDF, and what to do when you encounter an .xps file.
What XPS is
XPS was launched alongside Windows Vista in 2006 and standardized as ECMA-388 (then ISO/IEC 29500-2). The format ships as a ZIP archive containing XML documents that describe the page layout, plus embedded fonts and images. There are two extensions you will see in the wild:
.xps, the original Microsoft XPS..oxps, OpenXPS, the standardized version, which Windows 8 and later produce by default.
Functionally they are nearly identical. Most modern tools handle both.
XPS was built on the same idea as PDF: pin down exact visual layout so a document looks the same on every device. Where PDF uses a custom binary format with operators inherited from PostScript, XPS uses XML inside a ZIP. The thinking was that XML would be cleaner to author, parse, and transform than PDF's syntax.
Where XPS came from
Microsoft created XPS for two related reasons:
- Royalty-free PDF wanted to exist on Windows by default. Adobe controlled PDF tooling tightly in the mid-2000s; printing to PDF natively required third-party software. Microsoft wanted a built-in "print to fixed format" feature without depending on Adobe.
- Print pipeline simplification. XPS doubled as Windows's internal print spool format from Vista onward. The same XPS file the user printed could go straight to the printer driver. In theory, this made the print stack cleaner.
For a few years, Microsoft pushed XPS hard. Office could save as XPS. Internet Explorer had an XPS viewer. The Windows print spool used XPS by default.
Why PDF won
A few reasons, all reinforcing each other:
- Adobe relaxed. PDF became an ISO standard in 2008, ending Adobe's exclusive control. Free PDF tooling exploded.
- Cross-platform reality. PDF is everywhere, macOS Preview, every Linux desktop, every mobile OS, every browser. XPS is Windows-first; macOS and Linux support is rough at best.
- Reading ecosystem. Every browser, ebook reader, mobile device, and PDF tool already handled PDF. Even on Windows, users had Acrobat Reader for legacy reasons. Switching costs to XPS were never compensated by benefits.
- The print industry was already PDF. PDF/X had a 10+ year head start in the prepress world. XPS never penetrated.
- PDF kept evolving. PDF/A for archives, PDF/UA for accessibility, PDF/X-4 for transparent-aware printing, PDF 2.0 for modernization. XPS got the standardization to OpenXPS and then largely sat still.
- Tooling. PDF has a vast ecosystem, qpdf, Ghostscript, PDFBox, iText, pikepdf, MuPDF, hundreds of editors. XPS has, effectively, Microsoft tools plus a few converters.
By the late 2010s, XPS was a Windows-internal format that occasionally leaked into user-visible territory. By 2026, even Microsoft's own tools default to PDF for "print to file" workflows.
What to do when you receive an XPS file
If someone sends you a .xps or .oxps file, the workflow is almost always:
- Convert it to PDF
- Continue with your normal PDF tools
Options for the conversion:
- Windows 11 / 10. Open in the built-in XPS Viewer (older builds) or the Reader app, then File → Print → Microsoft Print to PDF.
- Online tools. Many free converters accept XPS and emit PDF.
- CLI. GhostXPS (
gxps -sDEVICE=pdfwrite -sOutputFile=out.pdf in.xps) and Ghostscript'smutoolfrom MuPDF can both convert. See our Ghostscript introduction. - Office. Open the XPS in Word (it may render as an image-only document) and Save As PDF. Quality varies.
Once converted, the PDF can go into your normal pipeline: edit, annotate, sign, compress.
What if you produce XPS by accident?
Most often this happens when "Microsoft XPS Document Writer" is set as a virtual printer and someone forgets to switch to "Microsoft Print to PDF" or "Save as PDF". To prevent it:
- Set "Microsoft Print to PDF" as your default printer for print-to-file workflows
- Remove or disable the XPS Document Writer if your organization has no XPS dependencies (in Windows Features)
- Train users to look at the printer dropdown before clicking Print
Are there any reasons to use XPS in 2026?
A few narrow cases:
- Legacy enterprise pipelines that already use XPS internally and have no compelling reason to migrate.
- Print drivers that consume XPS directly. These are vanishing fast.
- Workflows requiring XML-native fixed layout for downstream XSLT transforms. PDF's XML metadata via XFA or XMP can sometimes substitute, but if your pipeline is built around XPS XML structures, ripping it out is expensive.
For everyone else, the answer is to use PDF.
A small comparison table
| | XPS / OpenXPS | PDF | |--|--|--| | Standards body | ECMA / ISO | ISO | | First released | 2006 | 1993 | | Latest standardized version | ISO/IEC 29500-2 (~2012) | ISO 32000-2 PDF 2.0 (2017, revised 2020/2024) | | Native Windows support | Yes | Yes | | Native macOS / Linux support | Limited | Universal | | Mobile support | Poor | Universal | | Print industry adoption | None | Dominant | | Tooling ecosystem | Small | Massive | | Accessibility profile | Basic | PDF/UA | | Archival profile | XPS-A (rare) | PDF/A | | Digital signature support | Yes | Yes, mature | | Editing tools | Few | Many | | Practical recommendation for 2026 | Convert to PDF | Use as is |
Takeaway
XPS was a credible technical effort that lost to PDF for ecosystem reasons. The format works fine; nobody supports it widely. If you receive an XPS file, convert it to PDF and move on. If you accidentally produce one, change your default printer. PDF won the fixed-layout document war years ago, and the gap has only widened with PDF/A, PDF/UA, and PDF 2.0. For everyday editing of either format, once converted, Docento.app handles the PDF and lets you keep going.
