DOCX support and known limits
Separate package preservation, browser rendering, and editing support before choosing a document workflow.
This inventory was reviewed for superdoc 2.26.0-next.2 on 2026-10-21, using the default v2 browser runtime and its current Document API contracts. It lists known workflow limits, rather than every element in the OOXML standard. Recheck this page and the operation reference when upgrading; a previous release's result does not qualify a newer runtime.
Preservation, rendering, and editing are separate
Preserved means the DOCX retains content or package data on the tested save path. Rendered means the browser displays it. Editable means a particular operation can change it safely. Preserving an element does not establish that it is rendered or editable. A successful edit does not establish identical pagination in Microsoft Word.
SuperDoc edits the document's OOXML. Untouched package payloads can be copied from the source without reconstructing them; edited parts use the operation's serializer. That mechanism does not guarantee lossless behavior for every unknown element, every edit around it, or every DOCX producer. Validate the exact no-edit and edited round trips needed by your application, including relationships and supporting parts.
Known limits in this version
| Feature or workflow | Preservation and rendering | Editing or export limit |
|---|---|---|
| Fonts and pagination | Export retains the requested DOCX font family. A missing font can render with a browser fallback whose widths change line and page breaks. | Provide licensed font files or explicit substitutions, then compare the documents you deploy. A substitute pack does not guarantee Word-identical pagination. See Fonts. |
| Text-range extension highlights | Text-scoped highlights paint exact visible ranges. Hidden or unmounted text has no visible highlight until it becomes painted. | Only paint properties are supported; layout-changing CSS is outside the decoration contract. Unresolvable text ranges fail closed rather than styling the entire paragraph. |
| Tracked-range geometry in markup views | Explicit tracked-coordinate targets retain their canonical offsets when Original or Final hides revision text. Surviving ranges resolve against the current view; a range entirely hidden by that view has no painted rectangle. | Mapping requires matching canonical source and current projected text. When normalized fields, objects or merged paragraphs cannot be matched exactly, geometry is unavailable rather than guessed. Ordinary visible-coordinate queries keep their existing contract. |
| Numbering formats | The renderer recognizes a defined subset of OOXML numbering formats; retaining a list definition does not establish that its label renders correctly. | Formats outside that subset, such as russianLower, can leave missing list labels. A recoverable render diagnostic is reported through onException with diagnosticCode: 'UNSUPPORTED_FEATURE', diagnosticStage: 'render' and warning severity; it does not add warning UI or reject the whole document. The recognized formats are decimal, decimalZero, lowerLetter, upperLetter, lowerRoman, upperRoman, bullet, ordinal, custom, japaneseCounting, chineseCounting, chineseCountingThousand, hebrew1, and hebrew2. Validate label text and numbering behavior for your document. |
| Unknown XML, add-in data, and unrecognized package parts | Retaining package data does not make the feature visible or editable. | An edit that rewrites its owning part needs its own preservation check. Keep the original input and check saved XML and relationships before relying on an unknown feature. |
| Fields, tracked wrappers, and locked content controls | An imported carrier can survive a save while a particular range edit remains unavailable. | Text edits can refuse with text-range-in-field, text-range-in-unsupported-tracked-wrapper, or text-range-in-sdt. Rich HTML/Markdown edits use a different preflight and may return paste-target-unsupported. Inspect the concrete receipt. See Receipts and errors. |
| Anchored application metadata | Application data and its content-control anchor have a dedicated persistence contract. | Anchored ranges are body-only. Cross-table-cell, section, and block-control boundaries, unsupported overlap, and ambiguous legacy anchors are refused. This is narrower than general document addressing. See Application data. |
| Atomic review plans | A plan can relocate a root comment before deciding supported exact text revision IDs. | Review plans cannot mix core text, formatting, or structural steps. Comment creation, metadata changes, Custom XML writes, structural revisions, and secondary stories are outside this plan path. See Mutation plans. |
| Structural replacement with formatted content | The supported fragment retains paragraph and run formatting through export and reopen. | The documented rich-text SDT replacement is limited to a visible-text selection in one ordinary body paragraph and one mutating plan step. Tracked mode, cross-paragraph and nested targets, linked assets, and importing new style definitions are unsupported. See Mutation plans. |
| Temporary suggestion previews | Rollback restores the preview baseline; committing a changed choice creates one Undo entry. The existing document remains readable and rendered. | The lifecycle supports the documented plain-text and review operations in a standalone document. HTML, retained snapshots, and collaboration are unsupported. Other programmatic writes are blocked until the session finishes. Native interaction, Undo and Redo are also blocked by default; the optional onNativeEdit: 'cancel' policy restores the baseline before the native action continues. A baseline-equivalent choice does not create an empty Undo entry. See Temporary mutations. |
| Comparison-generated tracked changes | Compare/apply has an input-specific support boundary; retaining an existing carrier does not establish replay support. | Tracked replacement of shared style, numbering, or settings definitions is refused by default. Header/footer slot or topology changes are not supported as tracked replay. Other shapes can be refused even after comparison reports a candidate. See Document comparison. |
| Removing comments during export | Normal export preserves comments. Clean export produces a separate comment-free copy without changing the live document. | Clean export is supported on the resident save path. A source-fenced large-document save can refuse it when the main story would need rewriting. isFinalDoc and fieldsHighlightColor do not apply in v2 export; decide revisions explicitly before exporting final text. See Export options. |
An unsupported edit should return its documented typed failure. Do not treat a successful read, a capability-list entry, or an eligibility candidate as permission to ignore the operation's refusal. Preserve the original input and record the error code, revision, and exact requested operation.
Check an upgrade against your documents
Keep a representative input and compare its saved package after both a no-edit round trip and each operation your application performs. Inspect comment and revision identities, custom parts, relationships, fields, numbering, headers, footers, and notes that matter to the workflow. Then open the saved bytes in Microsoft Word and check native behavior and layout separately.
This inventory documents known boundaries. It is not a report of native Word verification, an exhaustive OOXML feature audit, or a guarantee that unlisted features have full rendering and editing support. Report an unsupported or lossy input with its exact package version, safe document, operation, and saved output so the relevant boundary can be investigated and updated for the next release.