Personal data in extracted text

What comes back, and what does not

A successful request returns two things: extracted_text, and a metadata object. Every request's metadata carries content_type, bytes, chars, and ocr. The structured tiers add format, tier, pages, and vlm on top of those four. See the full shape on /docs.

The response carries no document property. No author name, no document title, no EXIF field, no creation date. A file's own metadata can be wrong or stale even when it is present, so txtfetch does not surface it at all. A comment is different. It is part of the text, so a Word comment returns its reviewer's name inline. See headers, footers, footnotes and comments.

txtfetch does not store the documents you send it. Document bytes are held in memory for the extraction and then discarded. See /security for the full data-handling posture, and api/extract/src/redact.js's allowlisted, body-free log fields for what the request logger actually keeps.

Six places personal data hides in a document body

A document's visible page is not its whole content. Each row below is a real place text hides, what txtfetch does with it, and an in-browser tool to check your own file. Every tool listed here is client-side. It uploads nothing, so it is safe to test against a sensitive file.

Where it lands after extraction

Extracted text does not stop at the API response. It moves through your own pipeline, and each hop is a place a copy of it can persist.

The text can also carry instructions aimed at your model. See untrusted documents.

The hops below start the moment the response leaves txtfetch. For what happens to the bytes before that, inside txtfetch's own account, see the full trace. See where your file goes before it gets here →

Your log

txtfetch's own request logs carry an allowlisted, body-free field set: request ID, method, route, content type, size, and key ID. The document body and the extracted text never reach the logger. Check what your own service logs after it calls the API.

Your prompt

Extracted text you pass straight to a model becomes part of that request, wherever the model provider processes and may log it.

Your embedding provider

A chunk sent for embedding is visible to whichever provider computes the vector. The vector itself does not encode the text in readable form.

Your vector store

Some stores keep a second copy of the chunk text next to the vector, for retrieval. Whether yours does is a per-store fact, not a universal one.

See which stores keep the chunk text, per store →

What to do about it

txtfetch does not redact. The text comes back complete, by design. A parser that silently drops content is the exact defect /docs/quality-checks exists to catch, so txtfetch does not decide what counts as sensitive on your behalf. That decision stays with you, and here are the practical ways to make it.

• Resolve tracked changes before extracting. Accept or reject the changes in Word or LibreOffice before you send the file. /docs/tracked-changes has a script for Word files.
• Unhide and delete rows before extracting. Unhide a spreadsheet's rows and sheets, delete the ones that should not ship, and save before you extract.
• Filter the returned text before you embed it. Run a pattern check over extracted_text and hold back or redact a match before it reaches your chunker.

A short pattern check on the returned text can flag likely matches before you embed them. Read it as triage, not as a compliance control. A regex catches an obvious email address or phone number, and misses everything it was not written for.

import re

def flag_for_review(text):
    """Triage only. Flags likely email and phone patterns for a
    human to check — it is not a compliance control."""
    flags = {}

    emails = re.findall(r"[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}", text)
    if emails:
        flags["email"] = len(emails)

    phones = re.findall(r"\b\d{3}[-.\s]\d{3}[-.\s]\d{4}\b", text)
    if phones:
        flags["phone"] = len(phones)

    return flags

Frequently asked questions

Does txtfetch return a document's author or creation date?

No. The response carries extracted_text and metadata. metadata holds content_type, bytes, chars, and ocr on every request, plus format, tier, pages, and vlm on the structured tiers. It does not carry a document's own properties: no author, no title, no EXIF, no creation date. A comment is different. It is part of the text, so a Word comment returns its reviewer's name inline. See /docs/headers-and-notes.

Does txtfetch redact personal data before returning text?

No. The text comes back complete, by design. A parser that silently drops content is the defect /docs/quality-checks exists to catch, so txtfetch does not decide what counts as sensitive on your behalf. Strip or resolve the content you do not want before you extract, or filter the response after.

Does txtfetch store the documents I send it?

No. Document bytes are held in memory for the extraction, then discarded. See /security for the full data-handling posture and the request-logging work in progress.

Is a black box drawn over a PDF page a safe redaction?

Not on its own. A drawn rectangle is a graphics object placed on top of the page. It does not remove the text layer underneath, so the original characters are still in the file and can still be extracted. Remove the sensitive text from the document itself before you flatten or publish it.