liteparse
CLI Toolrun-llama/liteparse
A fast, open-source document parser with OCR and text extraction.
Overview
LiteParse is a standalone PDF parsing tool that provides spatial text parsing with bounding boxes, a flexible OCR system, and support for multiple output formats. It runs locally and integrates with Rust, Node.js, Python, and WASM.
README Preview
# LiteParse\n\n[](https://github.com/run-llama/liteparse/actions/workflows/ci.yml)\n|\n[](https://crates.io/crates/liteparse)\n|\n[](https://www.npmjs.com/package/@llamaindex/liteparse)\n|\n[](https://www.npmjs.com/package/@llamaindex/liteparse-wasm)\n|\n[](https://pypi.org/project/liteparse/)\n|\n[](https://opensource.org/licenses/Apache-2.0)\n|\n[Docs](https://developers.llamaindex.ai/liteparse/)\n\n\n\n> Looking for LiteParse V1? Follow this link to [the old code](https://github.com/run-llama/liteparse/tree/logan/liteparse-v1)\n\nLiteParse is a standalone OSS PDF parsing tool focused exclusively on **fast and light** parsing. It provides high-quality spatial text parsing with bounding boxes, without proprietary LLM features or cloud dependencies. Everything runs locally on your machine.\n\n**Hitting the limits of local parsing?**\nFor complex documents (dense tables, multi-column layouts, charts, handwritten text, or\nscanned PDFs), you'll get significantly better results with [LlamaParse](https://developers.llamaindex.ai/python/cloud/llamaparse/?utm_source=github&utm_medium=liteparse),\nour cloud-based document parser built for production document pipelines. LlamaParse handles the\nhard stuff so your models see clean, structured data and markdown.\n\n> [Sign up for LlamaParse free](https://cloud.llamaindex.ai?utm_source=github&utm_medium=liteparse)\n\n## Overview\n\n- **Fast Text Parsing**: Spatial text parsing using PDFium\n- **Flexible OCR System**:\n - **Built-in**: Tesseract (zero setup, bundled with the library)\n - **HTTP Servers**: Plug in any OCR server (EasyOCR, PaddleOCR, custom)\n - **Standard API**: Simple, well-defined OCR API specification\n- **Screenshot Generation**: Generate high-quality page screenshots for LLM agents\n- **Multiple Output Formats**: JSON and Text\n- **Bounding Boxes**: Precise text positioning information\n- **Multi-language**: Use from Rust, Node.js/TypeScript, Python, or the browser (WASM)\n- **Multi-platform**: Linux, ma
FAQ (5)
TroubleshootingWhy does liteparse return grid-projection coordinates for TextItem x and y instead of PDF points?
In liteparse v2.0.0-beta.2, TextItem.x and TextItem.y are mistakenly set to grid-projection coordinates (character column and line index) instead of PDF point coordinates. This is a known bug. As a workaround, use the dev CLI tool to extract raw PDF point coordinates:
python -m liteparse.cli extract --pdf-path <your_pdf.pdf>This command returns pre-projection items with correct
x, y, width, height, plus extra metadata. The team is working on a permanent fix; watch the repository for an upcoming release.How-toHow to parse PDFs using LiteParse on Cloudflare Workers or edge runtimes?
Use the @llamaindex/liteparse-wasm package. It provides a WebAssembly-based PDF parser compatible with Cloudflare Workers, Deno Deploy, Vercel Edge, and browsers. Install with npm install @llamaindex/liteparse-wasm and import the PDF parser directly. Check the package README for usage examples. The original Node.js-dependent liteParse package does not support edge runtimes due to native modules.
TroubleshootingHow to fix LiteParse dropping Japanese, Chinese, or Korean OCR text as "chart labels" on PDF pages with native text?
This is a bug in @llamaindex/liteparse 2.15.0. In crates/liteparse/src/ocr_merge.rs, is_chart_label treats every OCR token with three or fewer characters as a chart label. Tesseract often segments Chinese, Japanese, and Korean text into one-to-three-character words, so CJK prose images are misclassified. When a page also contains native text, chart_like_images then drops the image OCR, shown as skip(chart-figure) with LITEPARSE_DEBUG_OCR=1.
Fix: upgrade to a release containing PR #498. The fix applies the short-token length rule only to tokens without CJK characters, while keeping numeric-label detection. If building from source, patch is_chart_label so CJK tokens are not marked as labels solely because their character count is <= 3.
Verify with:
LITEPARSE_DEBUG_OCR=1 lit parse repro.pdf --ocr-language jpn --format json -qAfter the fix, CJK OCR lines should appear as ADD instead of skip(chart-figure). As a temporary workaround, process the CJK image on a page without native text or use a patched build.
TroubleshootingWhy does `lit parse` fail with `Conversion("Command failed: ")` when converting Office documents on Windows?
In lit 2.0.1 on Windows, the LibreOffice user-profile URI is generated incorrectly as file://C:\\Users\\..., but LibreOffice requires file:///C:/Users/... with three slashes and forward slashes. This causes soffice to exit with code 1 or hang without stderr output. As a workaround, convert the Office document to PDF manually first, then parse the PDF:
soffice --headless --invisible --convert-to pdf --outdir ./out input.docx
lit parse ./out/input.pdf --format text -o output.mdDirect soffice conversion works because it does not use lit's malformed temporary profile URI.
TroubleshootingHow to fix 'tessdata/eng.traineddata' error when using liteparse OCR?
Set the TESSDATA_PREFIX environment variable to the directory containing tessdata language files.
1. Download eng.traineddata from https://github.com/tesseract-ocr/tessdata/raw/main/eng.traineddata.
2. Place it in a folder (e.g., C:\\tessdata on Windows or /usr/share/tessdata on Linux).
3. Set TESSDATA_PREFIX to that folder path:
- Windows: $env:TESSDATA_PREFIX='C:\\tessdata'
- Linux/macOS: export TESSDATA_PREFIX=/usr/share/tessdata
If liteparse bundled Tesseract, the tessdata folder may be in node_modules/@llamaindex/liteparse/tessdata; set the variable to that path instead.