{"slug": "llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page", "title": "LlamaIndex's Document Parsing Protocol: 140 rules for a correctly parsed page", "summary": "LlamaIndex published working draft 0.1 of its Document Parsing Protocol (DPP), a proposed answer key for document parsing containing 140 rules covering text, tables, forms, charts and diagrams, each with example pages and expected output. The protocol grew out of the rules LlamaIndex annotators followed when labeling pages for ParseBench, the company's document parsing benchmark, and specifies handling such as preserving multi-row table headers via HTML colspan, marking empty form fields as [blank], converting charts to tables of their numbers, and rendering diagrams as Mermaid code when possible. LlamaIndex argues that without a shared definition of a correctly parsed page, parsers can capture every word yet produce outputs that mean different things, causing agents to return wrong answers.", "body_md": "Parsing a page into structured text or Markdown means making a run of judgment calls:\n\n- Is this block of aligned text a table, or just layout?\n- Does a header that spans two rows stay two rows, or get flattened into one?\n- Is a table that continues onto the next page one table or two?\n- Does a flowchart get described, converted to Mermaid, or skipped?\n\nDifferent parsers make different calls. So two parsers can capture every word on a page and still hand you outputs that mean different things. An agent works only from what the parser hands it, so if the parser groups a header wrong, the agent’s answer is wrong too. But there’s no shared definition of what a correctly parsed page looks like.\n\n The **Document Parsing Protocol (DPP)** is our proposed definition: an answer key for document parsing, with the reasoning behind each hard call. Today we're publishing working draft 0.1. Its 140 rules cover text, tables, forms, charts, diagrams, and more, and each comes with example pages and the output it expects. It grew out of the rules our annotators followed when labeling pages for [ParseBench](https://www.llamaindex.ai/blog/parsebench), our document parsing benchmark. \n\n## The same table comes out three different ways\n\nHere’s a sales page with two header rows. The years run across the top, each spanning its own columns, and the quarters sit underneath. 2023 also has a full-year column.\n\nThree parsers might turn that table into Markdown like this, shown down to the first data row.\n\nNow ask an agent for Q2 2024 systemwide same-shop sales.\n\n-  **A** pushed the quarters into the body, so the 4.1 % column has no year above it. The agent has to guess that it belongs to 2024.\n-  **C** dropped the years, so “Q2” matches two columns: 3.8 % and 4.1 %.\n-  **B** gets the right number, but only by inventing a label the page never printed: “2024 Q2”. Another parser might write “Q2 2024”, and code written for B would break on it.\n\nDPP counts all three as wrong. It keeps both header rows exactly as the page prints them. Markdown tables can’t show a header that covers several columns, so DPP uses an HTML table. Here’s DPP’s output for the same table:\n\nhtml\n\n```\n<table>\n  <tr> <th></th> <th colspan=\"5\">2023</th> <th colspan=\"3\">2024</th> </tr>\n  <tr>\n    <th><em>Fiscal year ending December,</em></th>\n    <th>Q1</th> <th>Q2</th> <th>Q3</th> <th>Q4</th> <th>FY</th>\n    <th>Q1</th> <th>Q2</th> <th>Q3</th>\n  </tr>\n  <tr>\n    <td data-level=\"0\"><strong>Systemwide Same Shop Sales</strong></td>\n    <td><strong>(2.0)%</strong></td> <td><strong>3.8 %</strong></td>\n    <td><strong>4.0 %</strong></td> <td><strong>5.0 %</strong></td>\n    <td><strong>2.8 %</strong></td> <td><strong>10.0 %</strong></td>\n    <td><strong>4.1 %</strong></td> <td><strong>2.7 %</strong></td>\n  </tr>\n  <tr>\n    <td data-level=\"1\">Ticket</td>\n    <td>6.3 %</td> <td>6.4 %</td> <td>9.5 %</td> <td>5.4 %</td>\n    <td>7.2 %</td> <td>8.8 %</td> <td>6.1 %</td> <td>1.9 %</td>\n  </tr>\n<!-- … -->\n</table>\n```\n\nThe 4.1 % now sits under Q2 inside the 2024 header, just as it does on the page.\n\n## The decisions go beyond tables\n\nTables are one part of it. Here’s how DPP handles the rest of a page:\n\n-  **Forms:** an empty field becomes`[blank]` , so you can tell it was left empty, not missed. Checkboxes stay as`[x]` and`[ ]` .\n-  **Charts:** they become a table of their numbers, with one row per category and one column per series. Printed values are copied exactly.\n-  **Diagrams:** they become diagram code, such as Mermaid, when it can hold every label and arrow. If nothing fits, the output describes what’s drawn and keeps every label.\n-  **Hidden and unreadable text:** text in the PDF that never shows on the page is left out. Text you can see but can’t read becomes`[illegible]` .\n-  **Positions:** if you ask, each element gets its location on the page, so any value can be checked against the source.\n\n## A shared answer key\n\nAnyone who builds a benchmark, labels data, or reviews parser output has to decide what the correct output for a page is. As the sales table shows, that includes decisions about structure, even when every word and number is right. Today each team makes those decisions privately, so two teams can grade the same output differently. We’re publishing DPP so everyone can work from the same written rules, and argue with them in the open.\n\n DPP also spells out which differences are acceptable. Wrapping table rows in `<thead>`  and `<tbody>` , for example, preserves the same information as leaving those wrappers out. Both forms conform, as long as a document uses one form throughout. A review should accept either. \n\n## Try DPP on a page\n\n DPP is live at [parseprotocol.com](https://www.parseprotocol.com/#adopt), with each source page shown beside its expected output. The fastest way to see what it does is to run it on a page. Pick Claude or ChatGPT on the site. For Claude, download the skill and upload it under Customize → Skills (skills need code execution). For ChatGPT, add the reference file to a chat. Then attach a page image and paste the prompt from the site. \n\n No page handy? Use the Apple sample page from the site. Check that the 6,485 printed in two cells survives in both, and that (565) keeps its parentheses. Then open the [walkthrough](https://www.parseprotocol.com/example) of that page, which explains the eight parsing decisions on it. \n\n DPP 0.1 is a working draft, and we want your input. If a rule breaks on one of your documents, or two rules point to different answers, show us. Open an issue or a pull request on [GitHub](https://github.com/run-llama/document_parsing_protocol) with the page and the output you’d expect, and we’ll work through it with you.", "url": "https://wpnews.pro/news/llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page", "canonical_source": "https://www.llamaindex.ai/blog/introducing-the-document-parsing-protocol", "published_at": "2026-10-30 15:55:41+00:00", "updated_at": "2026-10-30 16:17:02.995412+00:00", "lang": "en", "topics": ["ai-tools", "large-language-models", "ai-agents", "ai-research"], "entities": ["LlamaIndex", "Document Parsing Protocol", "ParseBench", "Mermaid"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page", "markdown": "https://wpnews.pro/news/llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page.md", "text": "https://wpnews.pro/news/llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page.txt", "jsonld": "https://wpnews.pro/news/llamaindex-s-document-parsing-protocol-140-rules-for-a-correctly-parsed-page.jsonld"}}