Pulling plain text out of a Word document with one call, no Word install required

"Extract the text from this Word document" sounds like a one-line task until the document turns out to have three rounds of tracked changes, a comment thread in the margins, and a footer repeated on every page. A naive extraction pass hands back all of it mixed together, with no way to tell the kept text from the deleted text once both have become "content." PDF4me's Extract Text from Word API is built specifically to give you control over that, not just pull raw text out of a .docx file.

Why plain OOXML parsing is not enough

Two paths usually get tried first. One is installing Microsoft Word or Office on a server and driving it through an interop library, which works until licensing at scale and unstable headless Office instances turn a document-processing job into an ops problem. The other is unzipping the .docx and parsing the OOXML XML directly, which works until a document with tracked changes or embedded comments shows up and the output is full of reviewer names, deletion markup, and boilerplate that never belonged in the final text.

The REST endpoint sidesteps both: send a Base64-encoded .docx, get back clean text, with four content-filtering options doing the real work.

The endpoint

POST https://api.pdf4me.com/api/v2/ExtractTextFromWord

Required parameters:

Parameter	Type	Description
docName	String	Source file name, with or without the .docx/.doc extension
docContent	Base64 (String)	The Word document content, Base64-encoded
StartPageNumber	Integer	First page to extract
EndPageNumber	Integer	Last page to extract
RemoveComments	Boolean	Strip comment text from the output
RemoveHeaderFooter	Boolean	Strip repeated header/footer content
AcceptChanges	Boolean	Accept tracked changes before extracting, rather than rejecting them

Optional:

Parameter	Type	Description
async	Boolean	When true, returns 202 Accepted with a Location header to poll instead of blocking

A synchronous call returns 200 OK with:

{
  "extractedText": "Extracted text content from Word document pages 1 to 3...",
  "fileName": "output.txt"
}

A working Python example

Verified against the official Python sample in pdf4me/pdf4me-api-samples (MIT licensed), field names and endpoint match the live docs page exactly:

import base64
import requests

api_key = "YOUR_API_KEY"  # from https://dev.pdf4me.com/dashboard/#/api-keys/
url = "https://api.pdf4me.com/api/v2/ExtractTextFromWord"

with open("sample.docx", "rb") as f:
    doc_base64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "docContent": doc_base64,
    "docName": "sample.docx",
    "StartPageNumber": 1,
    "EndPageNumber": 3,
    "RemoveComments": True,
    "RemoveHeaderFooter": True,
    "AcceptChanges": True,
    "async": False
}

headers = {
    "Authorization": f"Basic {api_key}",
    "Content-Type": "application/json"
}

response = requests.post(url, json=payload, headers=headers, timeout=300)

if response.status_code == 200:
    result = response.json()
    print(result["extractedText"])
else:
    print(f"Error {response.status_code}: {response.text}")

For large documents, set "async": True instead. The API returns 202 Accepted with a Location header, and polling that URL with the same Authorization header until it returns 200 gets the same extractedText payload once processing finishes. The official sample script handles both paths, sync and the polling loop, in one file, worth a look before writing your own retry logic.

The same options, in a no-code flow

The four content-filtering options are not REST-only. The n8n node exposes the same page range, comment, header/footer, and tracked-changes controls, and accepts input as binary data, Base64, or a URL, whichever fits the flow already moving the file around. The Zapier action, the Make module, and the Power Automate action all describe the identical underlying behavior, just as configuration fields inside their own flow builders. A team automating this inside Power Automate as part of a Microsoft 365 approval flow is calling the same extraction logic a backend service hits directly over REST. There is one engine under all five surfaces, not five different implementations to keep in sync.

Test it before wiring it up

Comment and tracked-change handling is configurable, not automatic, and every document set carries its own editing history. Before committing to a set of flags in code, PDF4me's interactive API Tester lets you upload a real .docx, toggle the page range and filtering options, and see the extracted text come back in the browser first. It catches a mismatched assumption about a document set before that assumption is baked into a pipeline.

Getting a key and the request contract

New to the API: the Getting Started guide covers account creation, generating a key from the developer dashboard, and making a first authenticated call. Every endpoint, this one included, follows the same V2 REST API contract: POST with a JSON body, the file as Base64 in docContent or a public URL in docUrl, docName carrying the extension that tells PDF4me which engine to route to, and a Base64-encoded API key sent as a Basic auth header.

What it will not do

This endpoint returns plain text, not structure. Tables come back as text, not as tables, and heading-versus-body distinctions are not preserved, so anything downstream that needs document structure intact needs a different step, not this one. And because comment and tracked-change handling is a choice rather than a default, it is worth deciding upfront, per document type, whether "final text only" or "everything including edit history" is the actual goal, since those are two different configurations of the same call, not two outputs from one default request.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com