Edit text and table cells in an existing DOCX with Python

Make two explicit changes

Install Community with pip install wolfdocx; this sample targets its public 0.1.0 API on Python 3.11 or newer. Prepare input.docx with the word Hello and a first table whose first row, first cell contains A1. The output must be a new path. Run the following Python against that reviewed input.

from wolfdocx import Document

with Document("input.docx") as doc:
    replaced = doc.find_replace("Hello", "Hi")
    if not replaced.passed:
        raise SystemExit(replaced.code)

    changed = doc.set_cell_text(
        table=1, row=1, cell=1,
        expected_old_text="A1",
        text="Updated",
    )
    if not changed.passed:
        raise SystemExit(changed.code)

    saved = doc.save("edited.docx")
    if not saved.passed:
        raise SystemExit(saved.code)
    print(saved.status, saved.changed_parts)

find_replace uses a regular expression and defaults to the main document part. Its implementation can match across run boundaries, so a word split into differently formatted Word runs is not automatically invisible to the search. This does not make protected field instructions or tracked-revision text ordinary editable text.

The cell operation is deliberately narrower: it names one table, row, and cell. Its coordinates are one-based, so table=1, row=1, cell=1 selects the first cell of the first row of the first table. The expected old text is a guard against updating the wrong version or an unexpectedly different cell.

Parameters that change the task

For literal searches containing regular-expression characters, escape the search with re.escape. For instance, a period normally means any character in a regular expression. Keeping this distinction explicit prevents a supposed literal replacement from changing a broader set of text than intended.

When omitted, the cell's optional guards are read from the current session tree. Supplying expected text is useful when your application already knows the reviewed value. A structural fingerprint is a separate check, not another spelling of the expected text. Do not fabricate a digest merely to satisfy a request.

Edits and publication are different steps

An applied edit changes the in-memory session. It does not itself publish an output file. If a later operation refuses, decide whether to abandon the session or deliberately save earlier accepted edits. The sample exits before saving when either edit fails, so this particular workflow does not publish a partially completed pair of edits.

The save receipt describes publication, including changed package parts. A report that says the intended part changed is useful evidence of scope, but it is not a visual comparison with Microsoft Word. Layout can still change when new text takes more space. Review representative outputs when text length or typography matters.

Keep the source and destination distinct. WolfDocx's save operation refuses an existing destination instead of silently replacing it. If another process claims your planned output path, choose a new destination or resolve that collision explicitly; do not automatically delete whatever is there.

What it does not do

• It does not promise an arbitrary complex or merged table cell is editable.
• It does not treat protected field or revision text as an unrestricted regex target.
• It does not refresh page-dependent field results or render a PDF.
• It does not guarantee unchanged pagination after making text longer.

Related guides

See reading before editing, handling refusals, and the text-replacement task guide.