# liteparse_samples: interactive demos for the LiteParse document parser > liteparse_samples is a set of browser-based demos for LiteParse, the local model-free document parser from LlamaIndex, including a side-by-side comparison against PyPDF and PyMuPDF, a visual citations sample that highlights keyword matches as bounding boxes on the source page, and a Claude Code skill that answers questions with cited source pages. **jerryjliu/liteparse_samples** — Interactive samples/demos for LiteParse: a fast, local, model-free document parser - Repository: https://github.com/jerryjliu/liteparse_samples - Website: https://developers.llamaindex.ai/liteparse/ - Stars: 525 · Forks: 52 - Language: HTML - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/jerryjliu-liteparse-samples ## What the repository actually is LiteParse Samples is a set of interactive demos showcasing LiteParse, which the README describes as a fast, local, model-free document parser by LlamaIndex. The word model-free is doing the work in that description. Most document parsing stacks in 2026 either run a model or call a hosted service, and both bring a dependency on someone else's compute and a per-page cost. LiteParse parses locally with no model in the loop, and this repository is where you can see what that produces. So this is a demonstration repository rather than a library. It is HTML as the primary language, and the top-level entries are the three sample directories, comparison/, visual_citations/ and research_docs/, plus assets/, data/, metadata.json and requirements.txt. The dependency list is three lines. ```bash liteparse pypdf pymupdf ``` That short list is itself evidence of the design. pypdf and pymupdf are the two parsers LiteParse is being compared against, and they are both pure Python or near it, so the comparison runs on the same machine with no model downloads and no API keys. The primary language is listed as HTML because the deliverable of each sample is a self-contained HTML page you open in a browser. The licence is not stated in the repository metadata, which is worth resolving before you reuse the sample code in your own project. The last push was on 2026-04-10, there are no GitHub releases, and the documentation lives at developers.llamaindex.ai/liteparse with the parser's own repository at github.com/run-llama/liteparse. ## The comparison sample: three parsers on real paperwork The Parser Comparison sample is the most substantive of the three, and it is the one to look at first if you are deciding whether LiteParse is worth adopting. It gives a side-by-side comparison of LiteParse against PyPDF and PyMuPDF on real government and financial documents. You see the original PDF on the left, then tab through each parser's extracted text on the right. The features list is short but the choice of documents matters. There are 8 document sections from 5 real-world PDFs, drawn from the FDIC, the Federal Reserve, CMS, the IRS and the WHO. An embedded PDF viewer sits alongside the parsed text, and there is per-document timing for each parser. Those source documents are the point. A parser comparison on a clean, single-column, digitally generated PDF tells you very little, because every parser handles that. A comparison across an IRS Form 1040, a Federal Reserve H.4.1 statistical release and a WHO indicators report is a different test, because those documents have the structure that actually breaks extractors: tables, multi-column layouts, headers and footers, and figures. The timing figure is the one to watch. It is measured per document, so you can see that a parser which is fast on one document is not necessarily fast on the next, which is exactly the kind of information a general benchmark average hides. To run it, you open the generated page directly. ```bash comparison/output/comparison.html ``` No server, no build step at read time. The page is static output produced ahead of time by a generate script, and it happens to be in the repository so you can open it without regenerating anything. ## Visual citations and what they do not do The Visual Citations sample demonstrates exact keyword search over parsed documents, showing precisely where each match appears on the source PDF page with bounding boxes highlighted directly on the page image. The README is careful about what this is, and the care is worth respecting. It is a simple substring match demo, not fuzzy or RAG-based search. That sentence is doing damage control for a reader who might otherwise assume the demo is showing semantic retrieval. The features are an interactive keyword search across all documents, bounding box overlays on rendered page images, and a side-by-side view of the source page and the parsed text with the matches highlighted. The mechanism is what makes it interesting for a parser evaluation. The bounding boxes are drawn on a rendered page image, which means the demo is asserting a mapping between a text position in the parsed output and a rectangle on the original page. For a parser that produces text with position information, that mapping is direct. For a parser that produces a flat text stream, it is not available at all. So the demo is really showing an output format property: whether the parser preserves geometry alongside the text. That matters for any downstream use where you want to point a reader back at the source, and it is the sort of thing a text-only sample would hide. Like the comparison, it is opened directly in a browser from visual_citations/output/visual-citations.html, and the README links to a Visual Citations guide in the LiteParse documentation for the fuller story. ## The research-docs skill, and the Claude Code path The third sample turns the demos into a tool you can invoke, and it does so through the Claude Code skill mechanism. The Research Docs sample asks questions about your documents and returns answers with visual source citations. The skill parses your documents, has Claude answer your question, and generates an HTML report with the answer and the cited source pages highlighted with bounding boxes. Installation is one command. ```bash npx skills add run-llama/liteparse_samples --skill research_docs ``` And usage is a slash command with a path and a question. ```bash /research-docs ./my-pdfs What is the total revenue? ``` The feature list covers parsing any document LiteParse supports, which the README enumerates as PDF, DOCX, PPTX, XLSX and images, plus plaintext. Then AI-powered answers with exact-quote source citations, bounding box highlights on the source page images, a PDF viewer toggle for each citation, and a self-contained HTML report. Two details are worth noting. The citation style is exact-quote rather than paraphrase, which ties back to the visual citations sample, and the report is self-contained, so it can be shared as a single file without a server. This sample sits on top of the other two. The bounding boxes that make the citations precise come from the same positional output the visual citations demo shows, and the parser that reads the documents is LiteParse itself. It is the sample with the most moving parts, and also the one that most clearly demonstrates why positional output matters. ## Regenerating the samples with your own documents All three samples are generated from a common data directory and a common configuration file, and the README documents the regeneration flow. The steps are: add your PDFs to the data/ folder, edit docs.json in the relevant sample folder to configure your documents and pages, then install dependencies and run the generation scripts. ```bash pip install -r requirements.txt # Regenerate comparison cd comparison && python generate.py # Regenerate visual citations cd visual_citations && python generate.py # Install research_docs skill cp -r research_docs ~/.claude/skills/research-docs # Then use: /research-docs ./data "Your question here" ``` Each sample has its own generate.py in its own directory, which is a simple and workable arrangement: the three demos share a data directory and a config format, but not a single build. The docs.json format is what you actually edit, and it is a list of document entries. ```json [ { "name": "My Document Title", "file": "my_document.pdf", "pages": [0, 1, 2], "source": "example.com", "desc": "Optional description (comparison only)" } ] ``` The fields have narrow meanings. The file field is the PDF filename and it must exist in data/. The pages field is a list of 0-indexed page numbers to parse, which means you parse selected pages rather than a whole document, and it is how you keep a demo quick. The source field is an attribution label, and the desc field is a description shown in comparison cards, used only by the comparison sample. The requirements are Python 3.9+ with liteparse, pypdf and pymupdf from the requirements.txt file. One thing to notice about the pages field: it is the mechanism for making the comparison meaningful on your own documents. Restricting to a handful of representative pages keeps generation fast, and choosing pages that include a table or a multi-column layout is what makes the output worth reading. ## Where these samples are the wrong thing to adopt There are three limits, and the first one is that this is not the parser. The first is that LiteParse itself lives elsewhere. The parser is at github.com/run-llama/liteparse and is documented at developers.llamaindex.ai/liteparse, while this repository holds the demos. If you want to parse documents in your own application, you install LiteParse, not these samples. What you get here is evidence about how it behaves and a set of HTML pages to look at. The second is that the comparisons are on a fixed corpus. Five government PDFs and eight sections is a small and very specific sample, and every one of them is a clean, digitally generated document from a public body. Real documents that break parsers are scans, forms with handwriting, tables spanning pages, and PDFs produced by office suites with unusual layouts. None of that is represented here. That is not a criticism of the sample, which is trying to be readable rather than exhaustive, but it does bound what the timings mean. A parser that handles an IRS form well has not thereby been shown to handle a scanned document, and the sample gives you no way to check that without supplying your own files and regenerating. The third is the licensing and the dependency on a hosted skill ecosystem. The repository licence is not stated in the metadata, and the research-docs sample depends on the Claude Code skill mechanism and on a specific upstream package path in the install command, run-llama/liteparse_samples. That path points at a different organisation from the one hosting this repository, which tells you the samples are published alongside the LiteParse repository and consumed through the skills registry. The honest alternatives depend on what you actually need. For choosing a parser, the best evidence is your own documents, and the regeneration flow here exists precisely so you can produce that evidence, which makes this a starting point rather than a destination. For the citation-with-bounding-boxes pattern specifically, that capability comes from the parser's output format rather than from these demos, so the decision is about whether the parser keeps geometry, which you can check by running the visual citations sample on one of your own pages. And for asking questions about a document set with citations, building that on a general retrieval stack over extracted text gives you semantic search and a real index, at the cost of the exact positional grounding these samples demonstrate. What these samples offer that a benchmark script does not is legibility. Seeing the original page next to three extractions is a far faster way to understand a parser's failure modes than a table of accuracy scores, and for a tool whose selling point is fidelity, that is the right way to evaluate it. ## Conclusion Adopt liteparse_samples if you are evaluating LiteParse against other PDF extractors, since the comparison sample gives you parsed output and per-parser timings on real government documents rather than a toy file. Do not adopt it as a document-processing library, because the parser itself lives in a separate repository. Before you regenerate anything, read the docs.json format, since that file drives which pages each sample processes, and note the last push was on 2026-04-10 with no tagged releases. ## FAQ ### What is liteparse_samples? It is a set of interactive demos showcasing LiteParse, a fast, local, model-free document parser by LlamaIndex. The repository contains a parser comparison sample, a visual citations sample and a research-docs Claude Code skill, with the parser itself living in the separate run-llama/liteparse repository. ### What does the parser comparison sample in liteparse_samples show? It gives a side-by-side comparison of LiteParse against PyPDF and PyMuPDF on real government and financial documents, with the original PDF on the left and each parser's extracted text tabbed on the right. There are 8 document sections from 5 real-world PDFs from the FDIC, Federal Reserve, CMS, IRS and WHO, with per-document timing for each parser. ### Is the visual citations sample in liteparse_samples a semantic search demo? No. The README states it is a simple substring match demo, not fuzzy or RAG-based search. It searches for exact keywords across the parsed documents and draws bounding box overlays on rendered page images, showing where each match appears on the source PDF page. ### How do I install the research-docs skill from liteparse_samples? Run npx skills add run-llama/liteparse_samples --skill research_docs, then invoke it with a path and a question, for example /research-docs ./my-pdfs What is the total revenue? It parses the documents, has Claude answer, and generates a self-contained HTML report with cited source pages highlighted. ### How do I regenerate the liteparse_samples demos with my own PDFs? Add your PDFs to the data/ folder, edit the docs.json in the relevant sample folder to set the file, the 0-indexed pages to parse, the source label and an optional description, then install requirements and run the generate.py script in the comparison or visual_citations directory. The requirements are Python 3.9+ with liteparse, pypdf and pymupdf. ## Sources - [Issues](https://github.com/jerryjliu/liteparse_samples/issues) - [jerryjliu/liteparse_samples on GitHub](https://github.com/jerryjliu/liteparse_samples) - [Project website](https://developers.llamaindex.ai/liteparse/) - [README](https://github.com/jerryjliu/liteparse_samples/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jerryjliu-liteparse-samples