DOCX File Documentation

---

Technical details

Feature	Value
Full name	Microsoft Word Open XML Document
File extension	.docx
MIME type	application/vnd.openxmlformats-officedocument.wordprocessingml.document
Format type	ZIP-based Office Open XML package (zipped XML)
Developer	Microsoft
Introduced	2007 (Word 2007); ISO/IEC 29500 in 2008
Standard	ECMA-376 (2006); ISO/IEC 29500 (2008)
Open standard	Partial — OOXML is ISO-standardised, but Word adds app-specific extensions
Container / base format	ZIP archive containing XML parts
Magic number (hex)	50 4B 03 04 (ASCII PK, the ZIP local file header)
Main parts	[Content_Types].xml, word/document.xml, word/styles.xml, word/media/
Compression	DEFLATE (standard ZIP compression)
Editable	Yes
Supported media	Text, images, charts, tables, hyperlinks, comments, headers and footers
Styling	Paragraph and character styles, themes, embedded fonts
Encryption	Supported (password protection, AES)
Digital signatures	Supported
Macros	Not in plain DOCX; VBA macros require the .docm format
Collaboration	Real-time co-authoring, comments, tracked changes (via OneDrive / SharePoint)
Interoperability	High — opens in Word, LibreOffice Writer, Google Docs, Apple Pages, WPS Office
Related extensions	.doc, .docm, .dotx, .odt, .rtf, .pdf, .txt
Specification	learn.microsoft.com/openspecs/office_standards/ms-docx/

What is a DOCX file?

DOCX is the default document format of Microsoft Word, introduced in 2007 with Word 2007 as part of Office Open XML (OOXML). It replaced the older binary DOC format. OOXML was standardised by Ecma International as ECMA-376 in December 2006 and adopted as ISO/IEC 29500 in 2008, which is why LibreOffice Writer, Google Docs, Apple Pages, and WPS Office all read and write DOCX without a Word licence.

The crucial fact about a DOCX is that it is not a single stream of bytes. It is an Open Packaging Conventions (OPC) package: a ZIP archive that holds a tree of XML documents, relationship files, and binary media, assembled according to rules defined in Part 2 of ISO/IEC 29500. The text itself is written in WordprocessingML, an XML vocabulary. Everything below describes the parts of that package and how they reference each other.

The OPC package and [Content_Types].xml

Because a DOCX is a ZIP container, the file begins with the ZIP local file header signature 50 4B 03 04 (ASCII PK). Rename a .docx copy to .zip, extract it with any archive tool, and the OPC package structure appears as folders and XML files:

report.docx  (ZIP / OPC package)
├── [Content_Types].xml          content-type map for every part
├── _rels/
│   └── .rels                    package-level relationships (entry points)
├── docProps/
│   ├── core.xml                 Dublin Core metadata: title, author, dates
│   └── app.xml                  application info, word/page counts
└── word/
    ├── document.xml             the main part: body, paragraphs, runs
    ├── styles.xml               style definitions referenced by pStyle/rStyle
    ├── numbering.xml            list and outline numbering definitions
    ├── settings.xml             document-wide settings
    ├── fontTable.xml            fonts referenced by the document
    ├── theme/theme1.xml         colour/font scheme
    ├── media/
    │   └── image1.png           embedded binary media
    ├── header1.xml, footer1.xml page headers and footers
    └── _rels/
        └── document.xml.rels    relationships out of document.xml

In OPC terminology each file inside the package is a part, identified by a part name that looks like an absolute path (/word/document.xml). Every part must have a declared content type, and that is the job of [Content_Types].xml at the package root. It uses two mechanisms. Default elements map a file extension to a content type, so one line covers every .xml or .png part. Override elements pin a specific part to a specific content type when the extension is not enough. The main document part, for example, is declared with an override of application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml. A consumer reads this manifest first, because it is how the package announces that it is a WordprocessingML document rather than, say, an XLSX spreadsheet, whose main part carries the SpreadsheetML content type instead.

The relationships model: _rels and rId

OPC parts do not reference each other by raw path. They reference each other through relationships, which keeps the internal wiring explicit and lets a part be moved or renamed without breaking every pointer to it. Relationships live in .rels files stored in a _rels folder next to the part they describe.

The package-level file _rels/.rels is the starting point. It names the top-level entry parts: which part is the office document (the WordprocessingML root), and which parts hold the core and extended properties. Each entry is a Relationship element with three attributes that matter: an Id (a string such as rId1), a Type URI that says what kind of relationship it is, and a Target giving the part name.

<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument"
    Target="word/document.xml"/>
  <Relationship Id="rId2"
    Type="http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties"
    Target="docProps/core.xml"/>
</Relationships>

The main part then has its own relationship part, word/_rels/document.xml.rels, that resolves everything document.xml points to: its styles part, its numbering part, its fonts, its headers and footers, its images, and any hyperlinks. This is where the indirection pays off. Inside document.xml, an inline image does not name a file; it names a relationship id. A drawing carries r:embed="rId7", and the consumer looks up rId7 in document.xml.rels to find Target="media/image1.png". The same pattern applies to hyperlinks (w:hyperlink with an r:id resolving to an external URL) and to headers and footers referenced from the section properties. Relationships come in two flavours: internal ones point to a part inside the package, and external ones (marked TargetMode="External") point outside it, which is exactly the mechanism behind remote-template loading discussed in the safety section.

WordprocessingML: body, paragraphs and runs

The text lives in word/document.xml. Its root is w:document, which contains a single w:body. Inside the body the content model is a sequence of block-level elements, the most common being the paragraph w:p and the table w:tbl. A paragraph in turn contains runs (w:r), and each run holds text in a w:t element. A run is the smallest span of characters that share one set of character-formatting properties, so a single sentence with one bold word is three runs: plain, bold, plain.

<w:document xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main">
  <w:body>
    <w:p>
      <w:pPr>
        <w:pStyle w:val="Heading1"/>
      </w:pPr>
      <w:r>
        <w:rPr><w:b/></w:rPr>
        <w:t xml:space="preserve">Quarterly </w:t>
      </w:r>
      <w:r>
        <w:t>report</w:t>
      </w:r>
    </w:p>
    <w:sectPr>
      <w:pgSz w:w="11906" w:h="16838"/>
      <w:pgMar w:top="1440" w:bottom="1440" w:left="1440" w:right="1440"/>
    </w:sectPr>
  </w:body>
</w:document>

Formatting is carried in property containers whose names end in Pr. A paragraph's optional first child is w:pPr (paragraph properties): alignment, indentation, spacing, and the paragraph's style reference w:pStyle. A run's optional first child is w:rPr (run properties): bold w:b, italic w:i, font size w:sz (in half-points, so w:sz w:val="24" is 12 point), colour, and the character style. Note the units in the example above: page dimensions and margins are expressed in twips (twentieths of a point, so 1440 = one inch), which is the measurement unit WordprocessingML uses throughout for layout.

At the end of the body sits w:sectPr, the section properties, which define page size, margins, orientation, columns, and the header/footer references for that section. A document with a single section carries one w:sectPr as the last child of the body; a document with multiple sections places an additional w:sectPr inside the w:pPr of the last paragraph of each earlier section.

The supporting parts: styles, numbering, settings, fonts

Most of what makes a document look consistent is not in document.xml at all; it is factored out into supporting parts that document.xml only references by name. word/styles.xml holds the definitions of every named style. A paragraph that says <w:pStyle w:val="Heading1"/> inherits its formatting from the Heading1 style defined there, so changing one style definition restyles every paragraph that uses it. word/numbering.xml defines list formats: the abstract numbering definitions (bullet glyph or number format, indentation per level, restart behaviour) and the concrete list instances that paragraphs bind to. word/settings.xml stores document-wide settings such as the default tab stop, compatibility options, and whether track-changes is on. word/fontTable.xml lists the fonts the document references so a consumer can substitute sensibly when a font is missing. Binary media, chiefly images, sit as ordinary files in word/media/ and are pulled in only through relationships, never by embedding the bytes in the XML.

ECMA-376, ISO/IEC 29500 and Strict vs Transitional

OOXML is defined across four parts of ECMA-376 / ISO/IEC 29500: Part 1 is the markup reference (thousands of pages of element and attribute definitions), Part 2 defines the Open Packaging Conventions, Part 3 covers markup compatibility and extensibility, and Part 4 originally held the transitional migration features. The standard defines two conformance classes. Transitional is the class Word 2007 shipped and remains the default that most software produces; it retains legacy compatibility features carried over from the binary DOC era (for instance certain legacy field and layout behaviours) so that older documents round-trip faithfully. Strict is a cleaner subset that removes those legacy items and was designed as the long-term interoperable target. A Strict DOCX uses different namespace URIs for its parts, so a consumer must recognise both namespace sets. In practice the vast majority of DOCX files in the wild are Transitional.

DOCX vs DOC vs DOCM

Three Word extensions are easy to confuse, and they differ at the first bytes of the file.

.doc is the legacy Word 97–2003 format. It is not a ZIP at all but an OLE2 / Compound File Binary (CFB) container, a little in-file filesystem of streams and storages. It begins with the CFB magic number D0 CF 11 E0 A1 B1 1A E1. The document text lives in a stream called WordDocument, and interpreting it reliably outside Microsoft software is hard, which was much of the motivation for moving to XML. See the DOC page for the CFB internals.

.docx is the OPC package described above, starting with 50 4B 03 04. Its main part carries the WordprocessingML document content type, and critically it contains no executable code.

.docm uses the identical ZIP+XML packaging as DOCX, with one addition: a binary part word/vbaProject.bin that holds compiled VBA macros, and a [Content_Types].bin override declaring the macro-enabled content type ...wordprocessingml.document.macroEnabled.main+xml. The extension and the content type are what tell Word a document may run code. A plain .docx cannot declare that content type or store vbaProject.bin; the macro capability was deliberately split into DOCM so that the everyday format carries no code. This same OPC-plus-macro-part pattern appears across Office: the macro-enabled spreadsheet counterpart to XLSX is XLSM, again distinguished only by the added VBA part and content type.

Why a plain DOCX cannot run code, and where the risks actually are

A plain DOCX cannot contain or execute VBA macros. There is no vbaProject.bin part and no macro-enabled content type in the manifest, so a normal .docx is a container of XML text and image bytes with no code path. Macros exist only in DOCM. Understanding the residual attack surface means naming the specific mechanisms.

The VBA auto-execution path. In a .docm, VBA code compiled into word/vbaProject.bin can run automatically through well-known entry points, chiefly the Document_Open event handler (and the legacy AutoOpen macro), which Word calls the moment the document opens if macros are enabled. This is the classic macro-malware trigger: the payload never needs a button click, only for the user to permit macros. The mitigation is layered. Protected View opens any document that carries a Mark-of-the-Web (the NTFS zone-identifier stream Windows attaches to files downloaded from the internet or received by e-mail) in a read-only sandbox with macros and editing disabled. Since 2022 Microsoft additionally blocks VBA macros outright by default in files that carry the Mark-of-the-Web, so a downloaded .docm shows a blocked-content banner rather than an easy "Enable Content" prompt. The practical rule stands: never enable content on a macro-enabled document you did not expect.

Remote-template injection. A DOCX (even a genuinely macro-free one) attaches to a template through a relationship. If that relationship is external (TargetMode="External") and its target is an http(s) URL, Word fetches the template when the document opens. An attacker who supplies a clean-looking .docx can point its template relationship at a remote .dotm that carries the actual macros, so the malicious code never ships inside the file that reaches the mail filter. The tell is an external template target in the relationship parts.

DDE. Dynamic Data Exchange fields were historically abusable to launch external commands through field codes rather than VBA, sidestepping the macro warning entirely. Microsoft has since disabled automatic DDE execution by default, but it remains a reason to be wary of documents that prompt to update linked fields. For confidentiality rather than integrity, a DOCX can be encrypted (modern Word uses AES within the OPC package), edit-restricted with a separate password, or digitally signed so a recipient can confirm the bytes have not changed since signing.

Frequently asked questions

Why does a DOCX reference images by rId instead of by filename?

The OPC relationship model decouples a reference from a physical part name. Inside document.xml an image is cited as r:embed="rId7", and word/_rels/document.xml.rels maps rId7 to media/image1.png. Because the mapping is external to the markup, a producer can rename or relocate the media part and only the one relationship line changes, and external targets (URLs) can be represented the same way as internal parts.

What is the difference between Strict and Transitional OOXML?

Both are conformance classes of ISO/IEC 29500. Transitional retains legacy compatibility features inherited from the binary DOC format and is what most software produces by default; Strict removes those legacy items, uses distinct namespace URIs, and was intended as the clean long-term interoperable form. A reader must handle both namespace sets, but Transitional dominates in practice.

How does a DOCM differ from a DOCX at the byte level?

They share identical OPC/ZIP packaging. A DOCM adds a word/vbaProject.bin part holding compiled VBA and declares the macro-enabled main content type in [Content_Types].xml. A plain .docx has neither, which is why it cannot store or run macros.

References

• Microsoft — [MS-DOCX] Word Extensions to the Office Open XML (OOXML) Format
• ISO/IEC 29500 — Office Open XML File Formats
• The Document Foundation — LibreOffice Writer

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.