Get started

The text is definitely in the file. It's just not in extracted_text.

Office documents are a zip archive of separate XML parts, not one flat stream. A parser that reads the visible body and stops silently drops whatever lives in the other parts.

looks-like

extracted_text:
"Slide 4\n\nQ3 roadmap overview"

// the deck's speaker notes on slide 4 — the actual talking points — never appear anywhere in the response.

The visible body text extracts fine. A specific part of the file's own structure just never made it into extracted_text.

why-it-happens

Office documents aren't one flat stream of text. They're a zip archive of separate XML parts, each holding a different piece of the document's content. Each part carries its own relationships back to where it's used. A .pptx keeps each slide's visible text in ppt/slides/slideN.xml. Speaker notes live entirely separately in ppt/notesSlides/, with their own files and their own relationship IDs. A parser that reads slideN.xml and stops silently drops the notes. That's not because the notes were empty, but because it never looked there.

The same shape repeats across the Office family. Grouped or nested shapes hide their text an extra level down inside the shape tree rather than at the top level. SmartArt diagram labels live in a separate diagrams/data*.xml part, disconnected from the diagram's visible layout XML. A .docx's tracked changes and comments are stored in their own parts (w:ins/w:del runs, comments.xml) rather than inline in the main body flow. And a .xlsx's string cell values are indices into a shared xl/sharedStrings.xml table, not inline text. A reader that doesn't resolve that indirection gets numbers pointing at other numbers instead of the words themselves.

None of this shows up as garbled or damaged text. The extraction genuinely just doesn't include it. The response can look completely clean and successful while quietly leaving out an entire category of content.

confirm-it

  • Every Office file is a zip archive. List its parts and grep for the text you expect to confirm it's actually there before assuming a parser bug.
  • Open the file in the native app (Word, PowerPoint, Excel, or LibreOffice). Check the specific view you suspect is missing: the notes pane, the comments pane, or a specific SmartArt diagram. Compare it against what extracted_text actually contains.

fix-it-yourself

Inspect the raw XML parts yourself

Confirms exactly what's inside the file before you go looking for a parser fix. Every Office file is just a zip you can unzip and grep.

bash

unzip -o deck.pptx -d deck_unzipped
grep -r "speaker note text" deck_unzipped/ppt/notesSlides/

Use a part-aware library for the specific content you need

python-pptx, python-docx, and openpyxl expose comments, tracked changes, speaker notes, and SmartArt text as distinct properties rather than flattening everything (or nothing) into one string.

python

from pptx import Presentation
prs = Presentation("deck.pptx")
for slide in prs.slides:
    if slide.has_notes_slide:
        print(slide.notes_slide.notes_text_frame.text)

what-txtfetch-does

txtfetch's Office parsing, via Apache Tika's POI-based parsers, reads slide body text AND speaker notes for .pptx, folding both into the response. See /extract/pptx for the specifics of what's covered part by part.

Grouped-shape and SmartArt text extraction depends on Tika's own POI support for that underlying part. That support is broad, but not exhaustive, for every nested or unusual shape structure. Tracked-changes and comment text are similarly parsed where Tika's OOXML support covers that part. A construct outside what Tika's parser resolves comes back the same way it would for any Tika-based pipeline: absent, not garbled.

If you depend on comments, tracked changes, or a specific diagram's text being present, verify it against a real extraction call on your actual file. Don't assume coverage. See /extract/docx, /extract/pptx, and /extract/xlsx for what each format covers.

what-it-costs-you-downstream

Missing speaker notes or comment text isn't a formatting nuisance in a RAG pipeline. It's silent data loss. The exact context, such as a slide's talking points or a reviewer's comment explaining a decision, never enters the vector store at all. Nothing about a successful-looking extraction call tells you it's gone.

faq

Does txtfetch extract PowerPoint speaker notes?
Yes. Tika reads both the slide body (ppt/slides/) and the speaker notes (ppt/notesSlides/) and includes them together in extracted_text. See /extract/pptx.
Why would text be missing from extraction without any error?
Office documents store different kinds of content in separate XML parts inside the zip archive: body text, speaker notes, comments, tracked changes, and SmartArt labels. A parser that doesn't resolve a specific part returns a perfectly successful response that simply never included that part's text. Nothing about the response signals the gap.
How do I check what's actually inside my Office file before assuming a bug?
Every .docx/.pptx/.xlsx is a zip archive. `unzip -l file.pptx` lists every part. Grep the relevant XML files (ppt/notesSlides/, word/comments.xml, xl/sharedStrings.xml) directly to confirm the text you expect is actually present in the file.

related-reading

Fix the text you already have.

The free cleaner repairs this damage in your browser. Nothing leaves the page.

Clean up your text →

Get an API key →