Microsoft Word Document (Open XML)

Rename a .docx to .zip. Your File Explorer Unzips It. What's Inside?

Every DOCX follows the Open Packaging Conventions: a ZIP archive containing [Content_Types].xml as its manifest, a _rels/ directory for relationship mapping, and a word/ directory holding the actual document parts. The main text lives in word/document.xml. Styles cascade from word/styles.xml. Fonts are declared in word/fontTable.xml. Embedded images sit in word/media/. To distinguish a DOCX from an XLSX or PPTX (all three are ZIP archives with the same PK magic bytes), parsers check [Content_Types].xml for the WordprocessingML content type.

This structure replaced a 25-year trade secret. The binary .doc format (1983-2008) was a proprietary Compound File Binary Format whose internals Microsoft deliberately left undocumented to maintain competitive advantage. When ECMA-376 standardized DOCX in 2006 and ISO/IEC 29500 followed in 2008, document internals became readable by anyone with a text editor. Microsoft simultaneously published the .doc binary specification under the Open Specification Promise — but by then, DOCX was already the default. Two conformance levels exist today: Transitional (allows legacy VML graphics and Microsoft-specific extensions) and Strict (ISO-defined elements only). Most DOCX files in the wild are Transitional because Word defaults to it. The spec keeps documents small in theory. In practice, a single Word doc routinely balloons into megabytes.

A Simple Word Doc Can Balloon to 15 MB. Why?

Make one word bold and Word creates three XML elements. The document stores text at three levels: a Paragraph (<w:p>) holds block-level properties like alignment and spacing. Inside it, a Run (<w:r>) represents contiguous text sharing identical formatting. Each Run wraps one or more Text elements (<w:t>) containing the characters. The xml:space="preserve" attribute on <w:t> ensures whitespace is not stripped.

Every formatting change — bold, italic, font switch, color shift — forces a new Run. The sentence "Hello World" becomes two Runs: one plain, one bold. A paragraph mixing five fonts contains at least five Runs. This is why document.xml can be large for simple-looking documents.

The styles system offsets some of this bloat. Four style types — paragraph, character, table, and numbering — cascade from document defaults through the style hierarchy to direct formatting. The "Normal" style anchors every paragraph. But direct formatting overrides still generate individual Runs for every deviation. Embedded images are stored once in word/media/ and referenced by relationship ID, so the same image appearing on ten pages adds no extra file size — a deduplication strategy that keeps image-heavy documents from ballooning. File size is one kind of hidden weight. What users don't see when they share the document is a different kind of leak.

Word Documents Remember Everything You Tried to Delete. Why?

Track changes in Word are not a UI feature — they are XML elements baked into the document file. Inserted text wraps in <w:ins>, deleted text in <w:del> with <w:delText> replacing <w:t>. Every revision records the author name, timestamp, and a revision session identifier (rsid) that tracks which editing session made each change. This data persists even after clicking "Accept All Changes" — the visible markup disappears, but the XML history stays unless purged with Document Inspector.

Legal filings have exposed confidential negotiation positions when opposing counsel unzipped the DOCX and read the revision XML. Government documents have leaked classified edits the same way. Beyond track changes, DOCX field codes once supported DDE (Dynamic Data Exchange) — commands like DDEAUTO that could launch executables when a document opened, without any macro warning. Microsoft patched this in 2017 (ADV170021) with a security update that disabled DDE auto-execution across all Word installations. The .docx extension itself is a security boundary: standard .docx files cannot contain VBA macros. Macro-enabled documents require the .docm extension, letting organizations block them at email gateways while allowing .docx through. Metadata leaks apply to any document. A different class of problems is specific to right-to-left scripts, where even correctly-authored content can render wrong.

Arabic Text in Word Needs Two Independent Direction Controls. Why?

Copy a paragraph of Arabic from one Word document into another and watch the text direction scramble. This happens because bidirectional text in DOCX operates at two independent levels: <w:bidi/> on paragraph properties sets the entire paragraph's base direction to right-to-left, while <w:rtl/> on individual run properties marks specific text runs as RTL. When the source and destination documents have different paragraph-level bidi settings, pasted text can flip direction mid-sentence. The fix: use Paste Special with "Unformatted Text" to strip inherited direction properties.

Mixed Arabic-English paragraphs trigger the Unicode Bidirectional Algorithm at the run level, with complex script fonts declared separately via <w:rFonts w:cs="...">. Section-level <w:bidi/> can set the default direction for an entire document section. Arabic diacritical marks (tashkeel — fatha, damma, kasra) are preserved within run text elements as Unicode combining characters inside <w:t>. Religious texts, educational materials, and formal government documents that require full tashkeel store these marks intact, and they survive format conversion as long as the target format supports Unicode normalization. Word's Arabic proofing tools support tashkeel insertion, and publishers of religious and educational Arabic content rely on DOCX to preserve these marks through format conversions.