Word document (docx) file format
A Microsoft Word document in the Office Open XML format.
- MIME type
- application/vnd.openxmlformats-officedocument.wordprocessingml.document
- Extensions
- .docx
- Category
- Documents
Magic-number signature
| 0x00000000 | 504B0304 | PK·· | 'PK' — it is a ZIP |
Inside the ZIP: '[Content_Types].xml' plus a 'word/' directory.
About the Word document (docx) format
A .docx is an Open Packaging Conventions package: an ordinary ZIP archive whose entries are XML parts plus any embedded media, tied together by relationship files. Renaming one to .zip and opening it shows the whole document — word/document.xml holds the text and paragraph structure, word/styles.xml the formatting, word/media/ the pictures. Nothing in the first thirty bytes of the file says 'Word'; the format is identified entirely by what the ZIP's directory lists.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 4 | Local file header signature | 50 4B 03 04. A .docx is a ZIP and this is the ZIP's first local file header, identical to the one at the front of a plain archive, an .apk or an .epub. Everything that makes the file a Word document is further in. |
| 4 | 2 | Version needed to extract | Minimum reader version times ten, little-endian like every ZIP integer. 20 for deflate is what Word writes; 10 appears on a stored entry. |
| 6 | 2 | General purpose bit flag | Bit 3 matters most here: when set, the CRC and both size fields below are zeroes and the real values follow the compressed data instead. Word writes packages both ways depending on whether it was streaming. |
| 8 | 2 | Compression method | 8 for deflate on essentially every part of a .docx, since XML compresses extremely well — a page of text is a few kilobytes of XML and a few hundred bytes on disk. Already-compressed media may be stored with method 0. |
| 10 | 2 | Last modified time | MS-DOS packed time — five bits of hour, six of minute, five of a two-second tick. Word normalises the timestamps of the parts it generates, so this rarely tells you when the document was actually edited; the real dates live in docProps/core.xml. |
| 12 | 2 | Last modified date | MS-DOS packed date, seven bits of year from 1980, four of month, five of day. Nothing before 1980 is representable, and there is no time zone. |
| 14 | 4 | CRC-32 | Checksum of this part's uncompressed bytes. It covers one entry only, so a .docx can have a perfectly valid CRC on its first part and a damaged one three parts later. |
| 18 | 4 | Compressed size | Bytes of deflate data following the header and the variable-length fields. FF FF FF FF sends the reader to a ZIP64 extra field, which a .docx effectively never needs. |
| 22 | 4 | Uncompressed size | Original length of the part. For [Content_Types].xml this is a few hundred to a few thousand bytes; the ratio against the compressed size is typically better than five to one. |
| 26 | 2 | File name length | 13 00 — nineteen bytes — whenever the first entry is [Content_Types].xml, which is what Word and every other OOXML writer emits first. This is the first field in the whole file whose value hints at what you are holding. |
| 28 | 2 | Extra field length | Usually zero for a Word-written package. Non-zero values carry ZIP64 sizes, Unix permissions or high-precision timestamps added by a repacking tool rather than by Word. |
| 30 | 19 | First entry name | The ASCII bytes [Content_Types].xml. This part is the package's map: it lists a content type for every extension and every override in the archive, and OPC requires it at the package root. Its presence at offset 30 is the cheapest positive test for OOXML of any flavour. |
| variable | variable | word/document.xml | The part that makes the package a Word document rather than a workbook or a deck. It is not at a fixed offset — find it through the central directory at the end of the file — but its name appearing there is the definitive test, alongside word/_rels/document.xml.rels which links it to its images and styles. |
| -22 | 4 | End of central directory signature | 50 4B 05 06, twenty-two bytes from the end when there is no archive comment. Readers start here, walk the central directory it points at, and only then know which parts the package contains — so a .docx with a healthy first header and a lost tail will not open at all. |
| -6 | 4 | Offset of the central directory | Absolute byte position where the directory begins, under the same empty-comment caveat. Prepend anything to the file and this number is measured from the wrong base, which is the mechanism behind most 'Word cannot open this file' errors on downloaded documents. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| Excel workbook (xlsx) | Byte-identical through the entire local file header and usually through the first entry name as well, because both start with [Content_Types].xml at offset 30. The only reliable separator is the directory at the end: a workbook lists xl/workbook.xml and an xl/ tree, a document lists word/document.xml and a word/ tree. The content types part itself also names the flavour, in an Override whose ContentType ends wordprocessingml.document. |
| ZIP | A .docx is a ZIP — the question is never whether but which. A plain archive has no required entry names at all, so the test is positive rather than negative: look for [Content_Types].xml at the root plus a _rels/.rels part. Without both, it is a ZIP that happens to contain some XML. |
| OLE2 / CFB | The format .docx replaced. A Word 97-2003 .doc is a Compound File Binary container opening D0 CF 11 E0 A1 B1 1A E1 with a stream literally named 'WordDocument' inside; a .docx opens 50 4B 03 04. Both open in the same Word, and Word decides by reading the bytes rather than the extension, which is why a mislabelled file still opens and a correctly labelled corrupt one does not. |
| EPUB | Both are ZIP packages of markup, and both are confused by naive detectors that stop at 'PK'. EPUB pins its first entry down absolutely — 'mimetype', stored uncompressed, no extra field, with application/epub+zip at offset 38 — while OOXML pins nothing at byte level and is identified by entry names. If offset 30 reads 'mimetype', you do not have a .docx. |
| docm | A macro-enabled Word document, and byte-identical to a .docx everywhere a hex editor is likely to look. The difference is a word/vbaProject.bin part inside and a different ContentType in [Content_Types].xml. This is the pair worth checking on anything from an untrusted source, because the extension is the only visible difference and it is trivially renamed. |
How these files break
- The tail is missing. Every local header and every compressed part can be intact while the file refuses to open, because a ZIP reader begins at the end-of-central-directory record and it is gone. Recovery means scanning forward for 50 4B 03 04 and rebuilding the directory from the local headers, which for a .docx usually recovers the text in full.
- Bytes prepended. An HTML error page or a PHP warning saved under a .docx name shifts everything, so the central directory's absolute offsets now point into the wrong place. Word reports the file as corrupt while the entire document is still present; deleting everything before 50 4B 03 04 fixes it.
- Text-mode transfer. Line-ending translation inside deflate streams leaves every header field readable and every entry name correct, so the package lists perfectly and then fails on a CRC mismatch when Word inflates word/document.xml. This is the failure that looks like a Word bug and is not.
- A part edited by hand and repacked wrongly. Because the parts are plain XML, editing one is easy and re-zipping it is where people go wrong: adding a directory entry for the folder itself, changing the entry name's case, or introducing a BOM in front of the XML declaration will all make Word refuse the package while every ZIP tool reports it as healthy.
- A truncated word/media part. Images are stored as ordinary ZIP entries, so a partially written PNG inside the package leaves the document text completely intact and readable while the picture renders as a broken placeholder. The failing CRC is on that one entry and nothing else.
Where the format stands today
The .docx package is the default word-processing format everywhere, and unusually for a Microsoft format it is a genuine open standard — ECMA-376 and ISO/IEC 29500 — which is why Google Docs, LibreOffice and Apple Pages all read and write it competently. The move from the binary .doc bought two things that matter outside Microsoft: recoverability, because the text is plain XML that survives a corrupted package, and size, because compressed XML is dramatically smaller than a compound file holding the same content. What it did not solve is fidelity between implementations — the standard is enormous, the parts are deeply interlinked, and a document round-tripped through a non-Microsoft editor commonly comes back with subtly different spacing, numbering or list indentation. So .docx is first choice for anything that must be edited collaboratively or reviewed with tracked changes, and the wrong choice for anything whose appearance must be identical on every machine, which is what PDF is for. Its practical downside is that a ZIP full of XML is an attractive delivery vehicle: the macro-enabled .docm sibling is byte-similar enough that mail filters have to look inside every package rather than trusting the extension.
Open Word document (docx) files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with Word document (docx) — compare their leading bytes.
| Format | First bytes | Extension |
|---|---|---|
| Excel workbook (xlsx) | 50 4B 03 04 | .xlsx |
| PowerPoint presentation (pptx) | 50 4B 03 04 | .pptx |
| ZIP | 50 4B 03 04 | .zip |
| OLE2 / CFB | D0 CF 11 E0 A1 B1 | .doc |
| EPUB | 50 4B 03 04 | .epub |