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 constantly breaks on new formats.
Who is it for?
Developers building LLM ingestion, RAG 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 — and 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 that 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 are meant to route through OCR automatically, so a scan and a native PDF are handled by the same call rather than needing separate handling upstream.
- Structure-aware parsing
Parsing is designed to preserve document structure — headings, tables, sections — rather than flattening everything into an undifferentiated text blob.
- No data retention
Documents are processed and discarded — nothing is stored after the response is returned, by design.
What's the hard part?
Structure-aware parsing across wildly different formats is the hard part — a PDF, a scanned form, and an HTML page each encode "this is a table" or "this is a heading" completely differently, and 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 stored
What does this prove we can do for you?
Turning messy real-world documents into clean, structured text at the format-detection and OCR layer is precisely the 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 opening up the endpoint.
02 What formats will it support?
PDFs, Office documents, HTML, email, and scanned images via automatic OCR — one endpoint regardless of input format.
03 Does it store the documents I send it?
No — the design is no data retention: documents are processed and discarded, nothing is stored after the response.
Turns PDFs, Office docs, HTML, email — even scans — into clean plain text over one HTTP endpoint. Built for LLM ingestion, RAG pipelines, and search indexing, 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.