In short
IntactFile repairs corrupted or unreadable .docxdocuments by opening them at the archive level and salvaging the text, styles, and images that survived. It runs entirely in your browser — your document is never uploaded, and you can confirm 0 bytes leave your device in the Network tab. The honest limit: text whose underlying data was truly destroyed can't be brought back, only the parts that are still readable.
Repair your document now
- Drop the .docx
- Repair runs locally
- Download the rebuilt document
To repair a corrupted Word document, you open it at the archive level (a .docx is a ZIP of XML parts), salvage the readable parts, and rebuild a valid package from them. IntactFile does that in your browser: drop the file, the engine reads it locally, and you download the result with a report of what came back. Your document is never uploaded.
Try Word's own repair first
Word ships a repair mode most people never notice, and it's free:File → Open → Browse, select the damaged file, then click the small arrow next to the Open button and chooseOpen and Repair. When Word can route around the damage, you're done. When it can't — it reports the file is corrupt, opens a blank page, or throws Word found unreadable content in name.docx and then recovers almost nothing — the package is damaged in a way Word's own path can't navigate. That's the case for archive-level repair, and to see why it works you need one fact about what a .docx actually is.
A .docx file is secretly a ZIP
Rename any healthy document from letter.docx toletter.zip and open it: you'll find folders of XML files.word/document.xml holds your actual text and paragraphs; other parts hold styles, fonts, and any embedded images, plus a[Content_Types].xml manifest and _relsrelationships that tie them together. Because it's a ZIP, atable of contents at the end of the file records where each part lives.
So "corrupted Word file" means one of two things: the ZIP container is broken (an interrupted save to a network drive or USB stick, a truncated email download — the table of contents is damaged while the text part survives), or one XML part inside is malformed while the rest are fine. Both are partial-damage situations, and that's exactly why ZIP-level repair recovers documents: the engine finds each surviving part by its own local header, no table of contents needed, and rebuilds a valid package from what's readable — the same mechanism asZIP repair, pointed at Word.
What gets recovered
Setting expectations precisely: body text, paragraphs, and styles recover best, because they live indocument.xml and the style part that archive-level salvage targets. Embedded images come back when their media parts survived. More fragile are tracked changes, complex fields, custom XML, embedded objects (OLE), and VBA macros in a.docm — they live in separate parts, and whichever of those were damaged or cut off don't return. The result report tells you what was rebuilt, so you know the gaps before you open the file.
What this can and can't fix
Can fix
- Broken ZIP container around an intact
document.xml— the common case - Truncated documents: every readable part before the cut is salvaged
- Files Word's Open and Repair rejects or opens blank
- A malformed XML part while the rest of the package is fine
Can't fix
- A
document.xmlwhose compressed data is itself destroyed — that text no longer exists in the file - Password-encrypted documents without the password
- Old binary
.doc(OLE) files — a different format entirely - Files that read 0 bytes — a data-recovery problem, not a repair problem
If the salvage comes back empty, we tell you why, and a failed repair is never charged.