txtfetch
Any document in. Clean text out.
What problem does it solve?
Turning PDFs, Office docs, HTML, and scans into clean text means maintaining a pile of parsing libraries and OCR infrastructure. That infrastructure constantly breaks on new formats.
Who is it for?
Developers building LLM ingestion, RAGRetrieval-Augmented Generation (RAG) retrieves relevant passages at query time and feeds them into an LLM's context. pipelines, search indexing, and document automation who don't want to run their own parsers.
Why are we building it?
Every extraction and RAG-ingestion engagement hits the same wall: PDFs, Office docs, HTML, scanned images. Every format needs its own parser, and OCR infrastructure that breaks the moment a new document type shows up.
txtfetch is what we're building so that wall stops being ours to maintain on every engagement. One HTTP endpoint takes any document in and returns clean text out, with no parsers for a client's team to maintain either.
How does it work?
- One endpoint, many formats
The plan is a single HTTP endpoint that accepts PDFs, Office documents, HTML, email, and scans, rather than a different integration per format.
- Automatic OCR for scans
Scanned documents route through OCR automatically. A scan and a native PDF are handled by the same call, with no separate handling needed upstream.
- Structure-aware parsing
Parsing is designed to preserve document structure: headings, tables, sections. It doesn't flatten everything into one undifferentiated text blob.
- No data retention
Documents are processed and discarded by design. Nothing is stored after the response returns.
What's the hard part?
Structure-aware parsing across wildly different formats is the hard part. A PDF and an HTML page each encode "this is a table" completely differently, and a scanned form encodes it differently again. The extraction has to normalise all of it into one clean structure, without losing what made the original document readable.
What does it do?
- One HTTP endpoint for 1,000+ document formats
- Automatic OCR for scanned documents
- Structure-aware parsing and format detection
- Clean JSON text out, nothing to configure
- No data retention: nothing is stored
What does this prove we can do for you?
Turning messy real-world documents into clean, structured text is the format-detection and OCR layer. It's the same document-extraction discipline we apply to client RAG and ingestion pipelines.
Where this shows up in client work
Questions, answered.#
The questions we get asked most, answered plainly: no hedging, no marketing copy.
01 Is txtfetch available yet?
Not yet. It's in build. Structure-aware parsing across formats is the problem we're solving before we open up the endpoint.
Link to this answer: Is txtfetch available yet?02 What formats will it support?
PDFs, Office documents, HTML, email, and scanned images via automatic OCR, all through one endpoint regardless of input format.
Link to this answer: What formats will it support?03 Does it store the documents I send it?
No. The design is no data retention: documents are processed and discarded, and nothing is stored after the response.
Link to this answer: Does it store the documents I send it?Turns PDFs, Office docs, HTML, email, and scans into clean plain text over one HTTP endpoint. Built for LLM ingestion and RAG pipelines, with no parsers to maintain.
This is the same discipline, real architecture decisions and an honest account of the hard part, that we bring to client engagements.