Recover a partial Markdown-to-Word batch without losing your corrections

Disclosure: I make AI Output Delivery Kit and sell an optional report pack. The converter, including batch export, is free; recovery requires no purchase.

A downloaded ZIP does not mean every selected report converted. AI Output Delivery Kit processes batch items separately: successful documents go into the archive, while failures appear in conversion-report.json. A second source of confusion is the editor. It displays the first selected file, but editing that text changes the single-export buffer, not the original batch files. This guide helps recover those two situations without confusing an old output with a corrected one.

Reproduce a partial failure safely

Create a practice folder containing three files. Use only this synthetic material. Save 01-valid.md with:

# Recovery practice
Original marker: AMBER.

Save 02-empty.md as a zero-byte file. Save 03-broken.md with:

# Practice actions

| Task | Owner |
| --- | --- |
| Review | Avery | Unexpected cell |

Select all three through the batch file picker, then choose Export selected files as ZIP. The expected archive contains 01-valid.docx and conversion-report.json. It should not contain DOCX files for the other two inputs. The empty document fails with an instruction to add Markdown text. The broken table fails with an inconsistent-column message identifying row 5.

Save the archive into a folder called attempt-1 and extract it there. Open the JSON report in a text editor. Expect three result entries: one with ok: true and two with ok: false. Successful entries use their output DOCX names; failed entries retain their input names. Read each error rather than inferring success from the presence of a ZIP. An entirely failed batch produces no ZIP and reports “No files exported.”

Prove which text each export reads

Before clearing the selection, check that the editor contains the AMBER marker. If your picker supplied a different first file, select 01-valid.md alone for this experiment. Change AMBER to COBALT in the on-page editor without saving any source file.

Choose Export editor as DOCX. This single download, named document.docx, should contain COBALT. Rename it editor-cobalt.docx. Now choose Export selected files as ZIP. The batch version of 01-valid.docx should still contain AMBER, because it reads the selected file rather than the edited buffer.

This is not a failed save inside the converter: the page does not write editor changes back to your local Markdown file. Copy useful edits into your source editor, save the .md file, and select the saved files again. Preserve the original separately if you need an audit trail. Do not assume a selection automatically refreshes after an external file edit.

Repair the cause and create a clean retry

For 02-empty.md, add a real report or remove the file from the intended batch. In this practice run, add # Practice note followed by No actions recorded in this fictional example. For 03-broken.md, determine whether the third cell was accidental or missing a column definition. Here it is accidental; replace the data row with:

| Review | Avery |

Save all corrections. If you want COBALT in the batch too, change and save 01-valid.md in your local text editor. Reselect the three corrected files. Export again and extract into attempt-2, leaving the earlier archive untouched.

Expect three DOCX files plus conversion-report.json, with all three entries marked ok: true. A table warning may still appear for the repaired table; that warning is a reminder to inspect it, not the same as a failed conversion. Check that the first document now contains COBALT and the repaired table has two columns and two rows, including its header.

Use the error to choose the next step

An empty-input error needs content or removal from the batch. An inconsistent-column error needs a source-table repair; putting the table in a fenced code block instead preserves text but does not produce editable table cells. A read error requires checking the selected file and choosing it again. The current input path also rejects files above 2,000,000 bytes; conversion rejects source above 500,000 characters. Split an oversized report at meaningful section boundaries and review the resulting documents together.

Warnings need separate attention. Images or detected math can produce an apparently successful document containing literal source instead of formatted report content. ok: true means conversion completed, not that the intended presentation or factual claims passed review.

Close the recovery with reconciliation

Compare the final report entries against your intended input list and inspect every output. Keep the final ZIP, corrected sources and a short note naming the superseded attempt. If retrying only failed files, combine outputs deliberately and check for duplicates; extracting repeatedly into one folder makes stale files harder to spot.

These examples were checked against the local converter and browser export flow. They establish the illustrated content and failure behavior, not Microsoft Word pagination or real iOS Safari compatibility. Open the final documents in the recipient's application before delivery. For routine preparation before any failure occurs, use the separate batch preparation guide.