LiteParse: A Local, PDFium-Based Document Parser with Bounding Boxes and Optional OCR

What LiteParse Solves and Who It Serves

LiteParse targets a specific gap: fast, local, spatial text parsing without proprietary LLM features or cloud dependencies. The README states it is a standalone OSS PDF parsing tool focused exclusively on fast and light parsing. It provides high-quality spatial text parsing with bounding boxes, and everything runs locally. This is for developers and engineers who need to extract text and layout information from PDFs, DOCX, XLSX, PPTX, and images, and who want to avoid sending documents to a cloud service. The primary audience is likely those building RAG pipelines, LLM agents, or document processing tools that require structure and position data, but who cannot or will not use a cloud parser. The project explicitly positions itself as a lighter alternative to LlamaParse, which is cloud-based and handles complex documents. So LiteParse is for the easy cases where speed and local execution matter more than handling the hardest documents perfectly.

The Parsing Pipeline: From File to Bounding Boxes

The architecture is visible in the README's flowchart. Input formats include PDF, DOCX, XLSX, PPTX, and images. These go through a Rust core that performs format conversion using LibreOffice and Rust image crates like resvg and usvg. Text extraction uses the PDFium C library. The pipeline then does selective OCR, merging native text with OCR results, and finally grid projection for spatial layout reconstruction. This grid projection is what produces the bounding boxes. The README notes that LiteParse follows the LlamaParse PDFium path extraction, but calls the shape rectangle bbox rather than PDFium's coords, and uses width and height rather than w and h. That is a concrete detail: the JSON output is not identical to PDFium's raw coordinates. It is a normalized representation. The flow is linear: convert, extract, optionally OCR, merge, project. The use of PDFium means that concurrent parses are serialized, which is why the worker pool mode exists in Python and Node.js to achieve true parallelism and hard timeouts.

Installation and the Unified CLI

Installation is straightforward across languages. For Node.js, you run `npm i -g @llamaindex/liteparse`. For Python, `pip install liteparse`. For Rust, `cargo install liteparse` gives the CLI, and `cargo add liteparse` adds the library. For browser use, `npm i @llamaindex/liteparse-wasm`. All versions except WASM ship with the same `lit` CLI. That is a notable design choice: one command line tool, regardless of the language binding. The CLI usage is simple. `lit parse document.pdf` parses a file. `--format markdown` or `--format json` controls output. `--target-pages "1-5,10,15-20"` selects pages. `--no-ocr` disables OCR. There are flags for vector graphics and text metadata extraction. The README also mentions using LiteParse as an agent skill, downloadable via `npx skills add run-llama/llamaparse-agent-skills --skill liteparse`, or by copying the SKILL.md file. This makes it easy to integrate into LLM agent workflows.

Markdown Output and Image Handling

LiteParse can render documents to Markdown, reconstructing headings, tables, lists, images, and links from the spatial layout. The README is explicit that this mode is purely heuristics and rule-based, so complex documents may not render perfectly, but it will be fast. That is an honest trade-off. Image handling is controlled by `--image-mode`, which accepts `placeholder` (default), `off`, or `embed`. `placeholder` emits image references in reading order, `off` strips images entirely, and `embed` emits the same references as placeholder. The key is that `--extract-images` is the only option that enables embedded-image extraction. `--image-output-dir` requires it and writes the extracted bytes to disk. In JSON output, each image has name, path, page bbox, intrinsic pixel dimensions, rotation, format, and duplicate relationship. Pixel bytes are never embedded in JSON. Identical image resources reuse the same output file. This is a thoughtful detail for storage efficiency. Library callers can opt in with `extract_images: true` in Rust, `extractImages: true` in Node/WASM, or `extract_images=True` in Python, defaulting to false. The separation of presentation mode from byte extraction is a clean design.

OCR Options and Complexity Detection

OCR is flexible. There is a built-in Tesseract option that is zero setup and bundled with the library. There is also support for HTTP servers, allowing you to plug in any OCR server like EasyOCR or PaddleOCR, or a custom one. The README mentions a standard, well-defined OCR API specification, which suggests you can write your own OCR backend if you follow that spec. This is useful for organizations that already run an OCR service. There is also a complexity detection feature: you can cheaply check whether a document needs OCR or heavier parsing, and then route, reject, or estimate cost before a full parse. That is a practical feature for pipelines that process many documents and want to avoid paying OCR costs on simple text PDFs. The exact mechanism is not detailed in the provided material, so you would need to check the docs for how to invoke it. But the existence of this feature is a strong point for cost control.

The Worker Pool Mode and Its Purpose

A significant design constraint is that PDFium serializes concurrent parses. That means if you try to parse multiple documents in parallel with the default setup, they will not actually run in parallel. To solve this, LiteParse offers a worker pool mode in Python and Node.js. The README describes it as parsing in persistent worker processes for true parallelism and hard per-parse timeouts. Rogue documents are killed, identified by name, and never stall the pipeline. This is a concrete answer to a real problem: a malformed or huge PDF can hang a parser indefinitely. The worker pool gives you a timeout mechanism, which is often missing in simpler parsing libraries. This is a feature that many production pipelines need, and it is good that it is built in rather than left to the caller. The trade-off is that you need to manage worker processes, which adds operational complexity. But for long-running services, this is likely worth it.

Limitations and When to Choose LlamaParse Instead

The README is unusually candid about limitations. It says that for complex documents, dense tables, multi-column layouts, charts, handwritten text, or scanned PDFs, you will get significantly better results with LlamaParse, the cloud-based parser. LiteParse's Markdown reconstruction is purely heuristics and rule-based, so complex documents may not render perfectly. That is a clear boundary: LiteParse is for clean, digital, text-based documents. It is the wrong tool for scans that require high-accuracy OCR, or for any document where layout reconstruction must be perfect. The README even positions LiteParse as a stepping stone: if you hit the limits of local parsing, you should consider LlamaParse. This is a honest self-assessment, and it is refreshing. The alternative, LlamaParse, is a cloud-based service that uses proprietary LLM features and handles the hard stuff so your models see clean, structured data. The difference is fundamental: LiteParse is local, fast, and rule-based; LlamaParse is cloud-based, slower, and uses AI to understand complex layouts. If your documents are simple, LiteParse is likely sufficient and much cheaper. If not, you need the cloud.

Maintenance, Licensing, and Upgrade Considerations

The project is licensed under Apache-2.0, which is permissive for commercial use, but you should verify the license implications for your own use case. The repository shows recent releases, with wasm-v2.14.2 and python-v2.14.2 pushed on the same day, indicating active maintenance. The last push date is 2026-08-27, which is recent. There is a note about LiteParse V1, with a link to the old code, suggesting that V2 is a significant rewrite. That means if you are upgrading from V1, you should expect breaking changes. The README is truncated, so the full upgrade path is not visible. The project has a docs site at developers.llamaindex.ai/liteparse, and a guide for the agent skill. For maintenance cost, the use of PDFium and Tesseract as dependencies means you need to handle those native libraries, but they are bundled. The worker pool mode adds operational overhead but is optional. Overall, the project appears well-maintained, with a clear versioning scheme and a community around LlamaIndex.

Editorial conclusion

Adopt LiteParse if you need fast, local, spatial text parsing with bounding boxes for clean PDFs and simple documents, and if you want to avoid cloud dependencies. Do not use it for dense tables, multi-column layouts, charts, handwritten text, or scanned PDFs, where the README itself points to LlamaParse for better results. Before adopting, verify that the Markdown reconstruction quality meets your needs for your specific document types, and check the worker pool mode (Python and Node.js) if you need hard per-parse timeouts. The project is under Apache-2.0, with active releases, so verify the latest version and test against your corpus.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes