Local-First Document Preparation for RAG, in the Browser
Pull-quote: “The document pile you want to make retrievable is, almost by definition, the most sensitive data you hold. The first architectural decision of a RAG project is where that pile is allowed to travel.”
Why this matters
Every retrieval project starts the same way: take the organization’s accumulated documents, contracts, procedures, reports, correspondence, and push them through a preparation pipeline that parses, chunks, and enriches them for embedding. Notice what just happened. Before the project has produced any value at all, it has proposed moving the most sensitive corpus the organization owns into a new processing environment. For a regulated team, that proposal is not a technical step. It is a security review, a data-transfer assessment, and a vendor evaluation, all standing between the team and a prototype.
The approval problem
| Question the review asks | Cloud preparation service | Local-first, in the browser |
|---|---|---|
| Where do the documents go? | A third-party environment, per its terms | Nowhere. They stay on the machine |
| What must be assessed? | Vendor, transfer path, retention, deletion | The tool itself, once |
| What happens on project cancel? | Deletion requests and attestations | Nothing to retrieve or delete |
| When can the team start? | After the review closes | Today |
The right column is the argument. When processing is client-side, the entire category of data-movement questions disappears, because no data moves. That is not a convenience for regulated teams. It is the difference between a RAG initiative that starts and one that waits a quarter for an approval that was never really about the technology.
What the browser can do now
The quiet enabler is that a modern browser is a capable processing environment. This is the design behind DocPrep-AI, an open-source document preparation tool: a browser-based pipeline that reads local folders directly, parses PDF, DOCX, XLSX, EPUB, HTML, and text with structure preserved, chunks content with live validation, and exports JSONL records ready for embedding, with all processing client-side. Documents never leave the machine, which is the property regulated teams need.
Your machine (everything below runs in the browser)
──────────────────────────────────────────────────
Local folder ──► Parse ──────► Chunk ─────► Catalog ─────► JSONL
(browsed (structure (live (25-column (ready for
directly, preserved, validation) master embedding)
no upload) 6 formats) schema)The output side matters as much as the input side. Records land in a 25-column master catalog schema with AI-assisted classification and tagging, so what leaves the pipeline is not a heap of text fragments but consistent, cataloged records. A dashboard makes the run visible end to end, which means an analyst can operate the pipeline without borrowing a data engineering team.
Local-first is a posture, not a limitation
The objection to local-first is usually scale: surely enterprise document volumes need a cluster. Some do, eventually. But the stalling point of most RAG projects is not throughput. It is the pilot phase, where a team needs to prepare a few thousand mixed-format documents and learn whether retrieval over them is any good. That workload fits comfortably on the machine the analyst already has, and doing it locally converts weeks of approval friction into an afternoon of work. If the pilot proves out, you scale the pipeline with evidence in hand. If it does not, no data ever moved, and nothing needs to be unwound.
Closing
Good retrieval starts with good preparation, and good preparation starts with an honest answer about where the documents may travel. For the sensitive piles that make RAG worth doing in the first place, the browser on your own machine is the shortest path from document pile to knowledge base. The tooling is open source, and a pilot costs an afternoon rather than an approval cycle.