PAGES File Documentation

---

Technical details

Feature	Value
Full name	Apple Pages document
File extension	.pages
MIME type	application/x-iwork-pages-sffpages
Format type	Word-processing document (iWork package)
Developer	Apple
Introduced	2005 (iWork ’05); current format since Pages 5 / iWork 2013
Open standard	No — proprietary, no published specification
Container / base format	ZIP package (modern); macOS bundle/folder (pre-2013)
Content encoding	IWA (iWork Archive) — Protocol Buffers in a Snappy stream
Magic number	50 4B 03 04 (“PK”, ZIP) at offset 0
Internal members	Index/*.iwa, preview.pdf, Metadata/, Data/
Preview	Embedded preview.pdf snapshot for Quick Look / recovery
Type registry	Integer type IDs mapped in TSPRegistry at runtime
Native app	Pages (macOS, iPadOS, iOS); Pages on iCloud.com (web)
Windows opener	None native — use iCloud.com or extract preview.pdf
Exports to	DOCX, DOC, PDF, RTF, EPUB, TXT
Related extensions	.numbers, .key, .docx, .doc, .pdf
Vendor page	apple.com/pages

What is a Pages document?

A .pages file is a document created in Apple Pages, the word-processing application in Apple’s iWork suite alongside Numbers (spreadsheets) and Keynote (presentations). Apple first released Pages in 2005 and now bundles it free on every Mac, iPad and iPhone. A Pages document holds formatted text and layout — letters, reports, flyers, resumes — and is the practical equivalent of a Microsoft Word DOCX file.

The format is proprietary to Apple and has no published specification, but its container is well understood. Since Pages 5 (iWork 2013) a .pages file is a ZIP package: rename it to .zip and it unpacks into a folder of internal files. The catch is that the document content is not stored as human-readable XML the way a DOCX stores it. Apple uses a binary format called IWA built on Protocol Buffers, so you cannot simply read the text out of the archive. The sections below explain how the package and that IWA encoding actually work.

The ZIP package and its members

A modern Pages file is a standard ZIP archive, which is why it begins with the local-file-header signature 50 4B 03 04 (PK). Unzipping it reveals a fixed set of members, each with a distinct job:

Document.pages  (a ZIP archive)
 ├─ Index/           .iwa streams: the actual document objects
 │   ├─ Document.iwa
 │   ├─ DocumentStylesheet.iwa
 │   └─ ... (Metadata.iwa, Tables, etc.)
 ├─ Data/            embedded images and other media
 ├─ Metadata/        document properties, build identifiers
 ├─ preview.pdf      full PDF snapshot of the document
 └─ preview-micro.jpg / QuickLook thumbnail

The real content lives under Index/ as one or more .iwa streams. Data/ holds embedded media such as inserted images, kept as ordinary files. Metadata/ records document properties and the build identifiers Pages uses to decide whether a given version can open the file. The preview.pdf is the single most useful member for anyone stuck without Pages: it is a complete PDF rendering of the document that Pages writes on save for Quick Look and iCloud thumbnails, so extracting it gives a read-only copy of the whole document even when the IWA streams are unreadable.

The IWA stream: Protocol Buffers wrapped in Snappy

Each .iwa file is an iWork Archive, and its structure is two layers deep. On the outside it is a Snappy-compressed stream, using Snappy’s framing format but not strictly to spec: iWork omits the required Stream Identifier chunk and drops the per-chunk CRC-32C checksum. The stream is a run of chunks, each with a four-byte header — one type byte (always 0x00, a compressed chunk, in practice) followed by a 24-bit little-endian length — and the compressed payload after it.

IWA stream = Snappy frames -> uncompressed byte stream

Uncompressed stream = sequence of archived objects:
  varint  length of the ArchiveInfo message
  ArchiveInfo (protobuf)   describes the payload(s) that follow
    -> one or more MessageInfo entries (type + length)
  Payload (protobuf)       the actual object, e.g. a paragraph, a style

Decompress the Snappy layer and you get a Protocol Buffers stream: the document’s objects — paragraphs, character runs, styles, tables — serialized one after another. Each object is preceded by a varint giving the length of an ArchiveInfo message, which in turn describes the MessageInfo payloads that follow. This is what makes a Pages file so much harder to read than a Word document: DOCX exposes its text as XML that any tool can grep, while Pages hides it in length-prefixed protobuf messages whose meaning depends on a schema Apple never published.

Why the IWA is hard to decode: the type registry

Protocol Buffers on their own do not name their message types — each object in the stream is tagged only with an integer type ID. Pages resolves those IDs at runtime through an internal table Apple calls the TSPRegistry, which maps each integer to a concrete message type (a paragraph style, a table model, a drawable, and so on). The mapping is not identical across the three iWork apps: Pages, Numbers and Keynote assign the same integers to different types, so a decoder built for one cannot blindly parse another. Reverse-engineering projects reconstruct these mappings by extracting the type registry from the applications themselves, which is how open-source tools recover text from .iwa streams at all. It also explains why the only fully reliable reader is Pages, and why a new iWork release can subtly break third-party decoders.

Older Pages files: the macOS bundle

Before Pages 5, an iWork ’05 through ’09 .pages document was not a ZIP file at all but a macOS bundle: a folder that Finder presents to the user as a single file. Inside were an index.xml.gz (a gzip-compressed XML description of the document, in the pre-IWA era when iWork did use XML) and a folder of assets. On disk this has no single-file magic number, because it is a directory; copied to a non-Mac file system it appears as a folder of loose files. Modern Pages still opens these old bundles, but the reverse is not guaranteed, and the two eras — readable gzipped XML then, opaque IWA now — are why advice about “reading a .pages file’s XML” only applies to the legacy format.

Reading and converting a .pages off Apple hardware

There is no Pages application for Windows or Android, so a recipient on those platforms cannot open a .pages directly, and Microsoft Word cannot read the format either. The supported cross-platform route is Pages on iCloud.com: any free Apple Account can sign in through a browser, upload the file, and download a copy as Word (DOCX) or PDF. That online export is exactly what the dominant “pages to word” user need calls for. The quick offline fallback exploits the package structure directly: copy the file, rename the extension from .pages to .zip, extract it, and open the preview.pdf inside for a faithful read-only rendering — no Apple device required, though you get the PDF snapshot rather than an editable document.

Frequently asked questions

Can I just unzip a .pages file to read the text?

You can unzip it — a modern .pages is a ZIP package — but the text is not readable inside. The document lives in Index/*.iwa streams, which are Protocol Buffers compressed with Snappy, not XML or plain text. The one member you can use directly is preview.pdf, a full PDF rendering of the document you can open in any PDF reader.

How do I turn a Pages file into an editable Word document?

Open the .pages in Apple Pages (Mac or iPad) or upload it to Pages on iCloud.com in any browser, then export or download a copy as Word (.docx). Word cannot open the .pages format itself, because the content is Apple’s binary IWA rather than the Office XML Word reads, so it must be exported from Pages first.

References

• iWorkFileFormat — IWA / iWork 2013 format documentation (reverse-engineered)
• Apple Support — Convert Pages, Numbers or Keynote files to Word, PDF and more
• Apple — Pages official page

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.