Local parsing with a deliberately narrow brain
LiteParse extracts documents without asking a language model to interpret every page. Its Rust core uses PDFium to read and render PDFs, Tesseract for built-in OCR, and spatial rules to reconstruct readable text and Markdown. The same engine is packaged for Rust, Python, Node.js, and WebAssembly. A shared lit command comes with the non-browser packages.
That architecture suits document ingestion where speed, privacy, and predictable cost matter more than solving every strange layout. A digital report can become text for search, Markdown for a retrieval pipeline, JSON with positioned text items, or PNG screenshots for a later visual step. Everything can run locally, including OCR, and Apache 2.0 licensing keeps the core usable in commercial systems.
The project does not pretend heuristics equal full visual understanding. Its README says dense tables, multiple columns, charts, handwriting, and difficult scans are better handled by LlamaParse, LlamaIndex's cloud service. That sales route is also a useful product boundary: LiteParse is the fast first pass, not a universal replacement for expensive document intelligence.
An unusually practical command line
Installation is simple for PDFs. pip install liteparse, the npm package, or Cargo supplies the parser, while Tesseract is bundled. The CLI can parse one file, a page range, or a directory; read a PDF from standard input; disable OCR for born-digital material; and write text, Markdown, or JSON. The default 1,000-page cap and configurable OCR workers are sensible safety controls.
The is-complex command is a standout. It cheaply inspects the text layer, labels pages as scanned, sparse, image-heavy, garbled, vector text, or annotation text, and exits nonzero when any page needs OCR. A pipeline can use that result to reject a file, turn OCR on, or send only difficult material to another service. This is more useful than blindly applying the slowest parser to every upload.
Screenshots add another escape hatch. An agent can parse text first, search it, and render only a page whose chart or layout carries the answer. The linked agent skill formalizes that workflow: parse once to a temporary file, search the saved output, and reserve screenshots for cases text cannot settle. Because it is distributed as a Claude-style skill under .claude/skills, LiteParse also fits Claude Code document tasks without becoming an MCP server.
More than plain text, but not one unified model
Structured output reaches well beyond a text dump. Callers can opt into bounding boxes, rich text metadata, vector paths, annotations, form fields, embedded images, tagged-PDF structure, content bounds, XFA packets, and provenance such as signatures and incremental-save markers. Most expensive or bulky fields are off by default. That restraint keeps ordinary JSON manageable.
Markdown reconstruction identifies headings, lists, links, images, and tables from spatial layout. Image references appear by default, but extracting the actual image bytes requires a separate option and output directory. This distinction is documented clearly and prevents an innocent Markdown request from unexpectedly filling storage with binary assets.
There is still a split between human-friendly structure and machine-friendly coordinates. Issue #403 notes that Markdown contains inferred blocks while JSON exposes line-level text items and bounding boxes, without linking a Markdown block back to its source region. Issue #407 proposes a block representation with provenance. Applications that highlight an answer on the original page cannot assume this mapping already exists.
Office files and OCR expand the setup
PDFs are the native path. Word, PowerPoint, spreadsheet, Apple office, OpenDocument, CSV, and related inputs first go through LibreOffice. That means another large system package, plus PATH configuration on some Windows machines. Images are converted natively in Rust, so the current README says ImageMagick is no longer needed.
Default Tesseract OCR keeps scans local and needs no separate server for English. Other languages require their trained data, especially in an air-gapped environment. Teams wanting another accuracy or performance profile can run the example EasyOCR or PaddleOCR HTTP wrappers, or implement the small documented API. Once that happens, LiteParse remains the client contract, but model deployment, language packs, hardware, and service monitoring become the team's responsibility.
Quality must be measured on real files. Issue #400 shows one sparse row causing a Markdown table to turn into column-wise prose. Issue #395 describes interleaved free text displacing a table header. Issue #153 reports rotated pages becoming gibberish. These are exactly the failures that can look plausible to downstream software, so a successful exit code is not enough for invoices, legal exhibits, or financial tables.
Healthy, fast-moving, and still converging
The repository was pushed on August 10, 2026. Version 2.11.1 packages for Rust, Python, Node.js, and WASM were released on August 5, with a fix for visible AcroForm values and an updated agent-skill guide. The combined open count was 31 issues and pull requests, and work in early August covered bounded-memory batches, tolerant page errors, screenshots, OCR servers, table fixes, and layout proposals. Maintainers also closed issue reports through matching patches, a good signal for a project moving this quickly.
Documentation is exceptional for the age of the tool. The README gives exact flags, defaults, format dependencies, output semantics, and expensive opt-ins instead of stopping at a demo. The remaining risk is cross-binding consistency: an open report says npm text output lacks page separators present in pip and Cargo, while another asks for Node end-to-end tests. Pin versions and run the same fixture suite against whichever binding you deploy.
LiteParse should be the first parser tried for ordinary local extraction, not the last parser forced onto every document. Its best role is to handle easy pages cheaply, expose evidence with coordinates and screenshots, and identify files that deserve heavier treatment. That honest division of labor makes it more useful than a parser that promises perfect Markdown and quietly returns convincing mistakes.