Does this tool upload my .docx anywhere?

No. Everything happens in your browser using the Web Platform's own DecompressionStream API. The file is read locally and never sent over the network. Only the finished text ever leaves your machine, and only if you choose to copy or download it.

Does it include text from tables?

Yes. Table cells are joined with tabs, and rows with line breaks. So a table extracts as a readable tab-separated grid, not one run-together wall of text.

What happens to tracked changes?

Deleted text, Word's markup, is excluded from the output, the same way txtfetch's API handles it. You get the document as it reads today, not a mix of current and struck-out text. Comments, footnotes, and headers/footers aren't included either. They live in separate parts of the file this in-browser tool doesn't read yet.

Why would I use this instead of just opening the file in Word?

This shows you exactly what a program gets when it extracts text from your file, which is usually less than what you see on screen. It's the fastest way to check, before you write any integration code, whether your actual documents will extract cleanly.

Does it work on .doc (the older binary format), not just .docx?

No. This in-browser tool only reads the modern, zip-based OOXML format (.docx). Legacy .doc is a completely different binary container (OLE2) that needs a real parser, not a browser API. txtfetch's API handles .doc directly; see the legacy-Office extraction guide.

Is there a file size limit?

This tool reads up to 25 MB entirely in your browser. Larger files, or a batch you want to automate, go through the same extraction via the API, which has no such limit.

Your .docx, as text. No code required.

Drop a real Word document below. Watch it become plain text right here, in your browser. Nothing is uploaded. It's the same read txtfetch's API gives you, just local.

Drop a Word, Excel, PowerPoint, or OpenDocument (.odt/.ods/.odp, zipped or flat) file below to see the actual text it extracts to. It runs entirely in your browser, and nothing is uploaded.

txtfetch — extract

Extracted text

The exact API call for :

curl

curl -X POST https://api.txtfetch.com/v1/extract \
  -H "Authorization: Bearer $TXTFETCH_KEY" \
  -F file=@__FILENAME__

Python

import os
import requests

with open("__FILENAME__", "rb") as f:
    r = requests.post(
        "https://api.txtfetch.com/v1/extract",
        headers={"Authorization": f"Bearer {os.environ['TXTFETCH_KEY']}"},
        files={"file": f},
    )

print(r.json()["extracted_text"])

JavaScript

import { readFile } from "node:fs/promises";

const file = new Blob([await readFile("__FILENAME__")]);
const form = new FormData();
form.append("file", file, "__FILENAME__");

const res = await fetch("https://api.txtfetch.com/v1/extract", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.TXTFETCH_KEY}` },
  body: form,
});

const { extracted_text } = await res.json();
console.log(extracted_text);

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"io"
	"mime/multipart"
	"net/http"
	"os"
)

type extractResponse struct {
	Status        string `json:"status"`
	ExtractedText string `json:"extracted_text"`
}

func main() {
	f, err := os.Open("__FILENAME__")
	if err != nil {
		panic(err)
	}
	defer f.Close()

	var body bytes.Buffer
	writer := multipart.NewWriter(&body)
	part, err := writer.CreateFormFile("file", "__FILENAME__")
	if err != nil {
		panic(err)
	}
	if _, err := io.Copy(part, f); err != nil {
		panic(err)
	}
	writer.Close()

	req, err := http.NewRequest("POST", "https://api.txtfetch.com/v1/extract", &body)
	if err != nil {
		panic(err)
	}
	req.Header.Set("Authorization", "Bearer "+os.Getenv("TXTFETCH_KEY"))
	req.Header.Set("Content-Type", writer.FormDataContentType())

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()

	var result extractResponse
	if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
		panic(err)
	}
	fmt.Println(result.ExtractedText)
}

whats-hard-about-docx

A .docx is a zip archive of XML. The document's text lives in word/document.xml as a tree of paragraphs (<w:p>) and runs (<w:r>), not a flat string. Tables are their own nested structure (<w:tbl>/<w:tr>/<w:tc>), and each cell contains its own paragraphs. Just grabbing the text nodes either loses the table's row and column shape, or runs every cell together with no separator at all.

Track changes make this harder in a way that's easy to miss. A deleted sentence doesn't disappear from the XML when a reviewer accepts the edit view. It's marked with <w:delText> and is still sitting in the file. A naive text dump includes text nobody wants in the final document. This tool reads the same tracked-change markers txtfetch's API does, and leaves deletions out.

Text boxes and pull quotes add a second layer. Their content lives in a nested <w:txbxContent> element. Word's own compatibility markup (<mc:AlternateContent>) can wrap that content twice, once for older readers and once for newer ones. Read both branches and every text box's text is duplicated in the output for no reason a reader would expect.

what-to-do-next

Got the text out and want the API call for it directly? The panel above already has it, with your file's real name. Extracting many documents, or files bigger than this browser tool's 25 MB cap? See the full Office-family extraction guide (DOCX, PPTX, XLSX) →

faq

Does this tool upload my .docx anywhere?: No. Everything happens in your browser using the Web Platform's own DecompressionStream API. The file is read locally and never sent over the network. Only the finished text ever leaves your machine, and only if you choose to copy or download it.
Does it include text from tables?: Yes. Table cells are joined with tabs, and rows with line breaks. So a table extracts as a readable tab-separated grid, not one run-together wall of text.
What happens to tracked changes?: Deleted text, Word's <w:delText> markup, is excluded from the output, the same way txtfetch's API handles it. You get the document as it reads today, not a mix of current and struck-out text. Comments, footnotes, and headers/footers aren't included either. They live in separate parts of the file this in-browser tool doesn't read yet.
Why would I use this instead of just opening the file in Word?: This shows you exactly what a program gets when it extracts text from your file, which is usually less than what you see on screen. It's the fastest way to check, before you write any integration code, whether your actual documents will extract cleanly.
Does it work on .doc (the older binary format), not just .docx?: No. This in-browser tool only reads the modern, zip-based OOXML format (.docx). Legacy .doc is a completely different binary container (OLE2) that needs a real parser, not a browser API. txtfetch's API handles .doc directly; see the legacy-Office extraction guide.
Is there a file size limit?: This tool reads up to 25 MB entirely in your browser. Larger files, or a batch you want to automate, go through the same extraction via the API, which has no such limit.

That was one file. The API does the queue.

This page read your DOCX on your own machine. The API reads a folder of them.

Read the quickstart →

Get an API key →