@jerryjliu0: We've created the world's fastest PDF parser ⚡️ And it's more accurate than any other open-source, model-free PDF parse…

I ran a test between yours vs PyMuPDF: - Winner: current Hermes local PDF path = PyMuPDF - liteparse: installed only in temp venv, benchmarked, then removed - Why not keep liteparse: ~2.1× faster, but worse reading order on two-column PDFs; it merges left/right columns into same

Do you have an example doc here? We’ll use to iterate on core capabilities

can't share, most of them are Physical Product Labels rendered as pdfs, you can download any from the web

Wonder how ours compares -

✅ I reran the 23-PDF benchmark: - Corpus: 23 local PDFs / 82 pages - invoices/labels/SDS/barcode PDFs/Hermes docs/research/sample scanned PDFs - Result: PSPDFKit/Nutrient still fastest - 4.58s total / 0.20s per PDF - ~40× faster than PyMuPDF total runtime - But: PSPDFKit

We'll bring OCR to pdf-to-markdown soon, we're focused on building out our cloud offering - https://nutrient.io/api/data-extraction-api/… - 5,000 credit free tier where you can run your benchmark with the different modes /parse. There will be network latency of course though. Our heuristic OCR is

We've created the world's fastest PDF parser ⚡️ And it's more accurate than any other open-source, model-free PDF parser out there (pymupdf, pypdf, markitdown, pdftotext, opendataloader, pymupdf4llm) Introducing LiteParse v2 - we rewrote the entire library into Rust and adapted it as native packages for Python and Node. It supports 50+ different document types, can be triggered directly or installable directly within your favorite AI agent. Blog: https://llamaindex.ai/blog/liteparse-v2-0-runs-everywhere?utm_medium=socials&utm_source=twitter&utm_campaign=2026-may-… Repo: https://github.com/run-llama/liteparse…

Also, it's completely open-source and free!

Cool

I ran a test between yours vs PyMuPDF: - Winner: current Hermes local PDF path = PyMuPDF - liteparse: installed only in temp venv, benchmarked, then removed - Why not keep liteparse: ~2.1× faster, but worse reading order on two-column PDFs; it merges left/right columns into same lines, which is worse for LLM/document reading. - Benchmark set: 4 real Hermes PDFs, 52 pages total - Quality: liteparse word coverage was high 99.4–100%, but layout/readability lost. - Activation needed: none — liteparse was not kept.

Do you have an example doc here? We’ll use to iterate on core capabilities

can't share, most of them are Physical Product Labels rendered as pdfs, you can download any from the web

Wonder how ours compares -

✅ I reran the 23-PDF benchmark: - Corpus: 23 local PDFs / 82 pages - invoices/labels/SDS/barcode PDFs/Hermes docs/research/sample scanned PDFs - Result: PSPDFKit/Nutrient still fastest - 4.58s total / 0.20s per PDF - ~40× faster than PyMuPDF total runtime - But: PSPDFKit

OCR disabled is buried bottom-right. real corpora are scans, rotated forms, multi-column. once vision lands in the pipe, parse time is rounding error vs the OCR pass. when does v2 wire the fallback?

amazing work! I would love to see how the result is compare to Docling.

Hi, do the text_items in the JSON outputs have bounding boxes or something else? Can we use them to draw boxes on the input page?

Definitely faster, but has systematic errors on tabular data that are absent in pymupdf. Looking forward to trying out the next versions.

Speed is great, but the real benchmark for agent workflows is: does it preserve semantic order on ugly PDFs? Two-column docs, tables, footnotes, scanned pages , if LiteParse handles those model-free, that’s a serious default upgrade.

@grok dose it also build or only read?

Proud to be in the contributor list of v1

Thank you, I have been using the LiteParse for while now!

Does it do OCR?

the fact that it's model-free is the real selling point here, most teams i've seen trying to build doc pipelines get stuck on gpu costs before they even hit scale. 100x on cpu alone changes the math completely

Parser speed is table-stakes. In credit the loan tape lands in thirty schemas from thirty originators. The bottleneck isn't extraction, it's mapping every shape to one canonical model the agent can act on. Parse-quality wins the demo; schema-normalization wins the workflow.

Correct me if I'm am wrong. So for on device it will still use pdfium and for complex files, it's and LLM call to the cloud, right?

This comes at the perfect moment :), won't have to do a separate worker with docling it seems. Do you have a timeline on when will the rust documentation be available in the docs? (The rust tab it's currently empty)

You get smoked by pymupdf on everything except 457 pages..