Infrastructure · Reviewed 2026-07-29
LiteParse
STEADY · 85/100
A deliberately un-clever document parser — Rust, local, no API key, no LLM in the loop — and that restraint is exactly what makes it dependable infrastructure for agents.
Visit LiteParse →LiteParse is the rarest thing in the 2026 document-parsing market: a tool that does not want to be an AI product. It is written in Rust, runs entirely on the machine, and states plainly that it uses no LLMs and no API keys. In a category where nearly every competitor routes your documents through someone else's inference endpoint and bills per page, choosing determinism is a real position, not a limitation. The feature list is the honest kind — spatial layout preserved, bounding boxes for every text line, Markdown rendering with tables and headings, Tesseract OCR built in with a pluggable server, Office formats via automatic conversion. Nothing there is a claim about intelligence; all of it is a claim about mechanics, which is the sort of claim that either works or visibly doesn't. For agent builders the surface is unusually complete: CLI, library bindings for TypeScript, Python and Rust, a browser/WASM path, and an MCP server with its own install page. That combination means an agent can drive it in-process, out-of-process, or over MCP without the vendor mediating anything. The caveat is that everything we can see is documentation. The page carries no adoption numbers, no benchmark comparison against LlamaParse (the vendor's own cloud product) or the wider OCR field, and no statement of licence or version cadence on the surface we captured — so parity claims like OCR accuracy remain unverified from the public surface. Backing from LlamaIndex reduces the continuity risk that usually shadows a young parsing library, but it also raises an unanswered question the docs do not address: where LiteParse ends and the paid LlamaParse begins.
Why STEADY
STEADY (85) because the capability surface is broad and concretely specified (spatial parsing, bounding boxes, OCR, Office formats, four language targets plus WASM), the local/no-API-key architecture removes the vendor-dependency and per-page-cost risk that dominates this category, and an MCP server plus CLI make it directly drivable by agents. Not VITAL because the captured surface is documentation only: no adoption signal, no independent or self-published accuracy benchmark, no licence or release cadence stated on the page, and no articulation of how it relates to the vendor’s own paid LlamaParse — so durability and quality claims remain unverified rather than disproven.
What it does well
- Parses locally with no cloud dependency, no LLM and no API key — documents never leave the machine
- Preserves spatial layout and returns bounding boxes per text line, not just flattened text
- Renders structured Markdown (headings, tables, lists, images, links) aimed at RAG pipelines
- Ships four consumption paths — CLI, TypeScript/Python/Rust libraries, and browser WASM
- Provides an MCP server with a dedicated install page, so agents can call it without custom glue
- Handles scanned input via built-in Tesseract OCR, with a pluggable external OCR server
What it fails at
- No accuracy benchmark published on the captured surface — OCR and layout quality are unverified
- No adoption, download or production-use signal anywhere on the page
- Licence and release cadence are not stated on the documentation surface we captured
- Relationship to the vendor’s paid LlamaParse is undefined — unclear which workloads are expected to graduate
- No pricing or support statement, so commercial supportability cannot be assessed
Best for
- Agent pipelines that must parse documents without sending them to a third party
- Real-time or latency-sensitive extraction where a network round-trip per page is unacceptable
- Coding agents and local workflows needing bounding boxes for citation or visual grounding
- Teams under data-residency constraints that rule out cloud OCR entirely
- Polyglot stacks — the same engine is reachable from Node, Python, Rust and the browser
Not recommended for
- Teams that need a contractual accuracy SLA — none is published
- Workloads depending on LLM-based semantic understanding of documents (this is deliberately mechanical parsing)
- Buyers who need a documented support path or commercial licence before adoption
- Anyone selecting on published benchmark parity against incumbent OCR vendors
Compared to
-
autoscrape-labs-pydoll
static-document-parsing
Both are local, open-source extraction tools with no vendor in the request path, but they address different inputs: pydoll extracts from live web pages via browser automation, LiteParse from static documents (PDF, Office, images). They are complements in a pipeline more often than alternatives.
Agent relevance
CLI MCP SDK Behavioral-testable
Three first-class paths, all documented on the captured surface: an MCP server with a dedicated "Install MCP Server" page for tool-calling agents; a CLI for shell-driven agents; and TypeScript/Python/Rust libraries (plus browser WASM) for in-process embedding. No API key or account is required, so an agent can adopt it without credential provisioning — unusually low friction for this category.
Agent-friendly score: 9/10
What we saw
1 screenshot captured by the Hlido engine during the reviewed run (run-1ceb1cea078c4f36-developers-llamaindex-ai). Our own captures — not vendor marketing material.
Evidence
scorecard.json · registry · methodology
Embed this trust badge
Markdown
[](https://hlido.eu/check/?agent=run-llama-liteparse)HTML
<a href="https://hlido.eu/check/?agent=run-llama-liteparse"><img src="https://hlido.eu/badge/run-llama-liteparse.svg" alt="Hlido trust score"></a>