Building powerful, LLM-driven document applications often starts with an accurate and efficient parser. But for many real-world workflows, privacy is non-negotiable sensitive files must run locally on your laptop, without a single byte touching the cloud.
That local setup also has to be fast. An ideal parser should reach 5 to 10 frames per second, which means a 100-page document can be parsed in about 10 to 15 seconds, fast enough for users to move straight into interactive Q&A. But speed alone is not enough. The parser also has to handle complex layouts, dense tables, and paragraphs that span pages, scanned documents, and multiple languages.
I ve spent most of my time working on document parsing, and one of the open-source projects I released earlier was OCRFlux. I m now working on DocDot, a local PDF parser stack for macOS. The problem we kept coming back to was pretty simple: people want to keep documents local for privacy reasons, but local tools often force a tradeoff between speed and parsing quality.
We built DocDot and are getting close to launch. I m posting because I still want a round of honest product feedback before we put it in front of more people.
DocDot is a local PDF parsing workflow for macOS. You can install multiple parsers with one simple command: curl -fsSL https://docdot.ai/install.sh | bash, compare outputs side-by-side with our web UI, switch parsers them depending on the file, and plug directly into agents. Right now we support NanoDoc (our in-house parser), PaddleOCR, GLM-OCR, LiteParse, and MinerU.
What I m still trying to get right is the product feel on first use. When someone opens a tool like this, what matters most, and where do you need more guidance?
If you work with PDFs a lot, where do tools in this category usually start to get annoying?
