> This page is for version v2026-02-09 (default). > For other versions, use one of these documentation indexes: > - v2026-02-09 (default): https://docs.extend.ai/2026-02-09/llms.txt > - v2025-04-21: https://docs.extend.ai/2025-04-21/llms.txt > - v2024-12-23: https://docs.extend.ai/2024-12-23/llms.txt > ## Documentation Index > Fetch the complete documentation index at: https://docs.extend.ai/llms.txt > Use this file to discover all available pages before exploring further. > > ## API version > The current API version is `2026-02-09`, served at the site root (no version prefix in URLs). > If this page URL contains `/2025-04-21/` or `/2024-12-23/`, you are reading an older API version. > Prefer the current docs at https://docs.extend.ai/llms.txt unless the user explicitly needs that older version. > Do not treat older-version pages as the source of truth for new integrations. # Parsing Best Practices > Practical tips for getting the best results from Parse — retrieval quality, accuracy, speed, and cost. This guide covers practical tips for getting the best results from Parse: tuning for retrieval quality, accuracy, speed, and cost. --- ## Use section-based chunking for RAG By default, Parse returns one chunk per page. For retrieval, you usually want chunks that are complete semantic units — so each one can be embedded and retrieved on its own without splitting a table or cutting off a paragraph mid-thought. Setting `chunkingStrategy.type` to `section` splits the document at logical boundaries (headings, tables, figures) instead of arbitrary page breaks. Use `minCharacters` and `maxCharacters` to keep chunks within your embedding model's ideal range. ```json { "config": { "target": "markdown", "chunkingStrategy": { "type": "section", "options": { "minCharacters": 500, "maxCharacters": 2000 } } } } ``` Section chunking requires `target: "markdown"`. See [Chunking strategy](/parsing/configuration#chunking-strategy) for the full options. --- ## Use HTML for complex tables Markdown tables can't represent merged cells, nested headers, or multi-row cells — so complex tables often come out misaligned. Set `blockOptions.tables.targetFormat` to `html` to preserve the original table structure. ```json { "config": { "blockOptions": { "tables": { "targetFormat": "html" } } } } ``` If your tables look broken, switching to `html` usually fixes it. For tables that span multiple pages, also enable `tableHeaderContinuationEnabled` so headers repeat on each page. See [Tables](/parsing/configuration#tables). --- ## Enable agentic processing only when needed Agentic processing uses a vision language model to review and correct parsing output. It meaningfully improves accuracy on hard documents, but it adds latency and consumes more credits — so it's a deliberate accuracy-vs-speed-and-cost tradeoff, not an always-on setting. It's off by default; enable it only where it helps: * **`text.agentic`** — corrects low-confidence OCR. Enable for handwriting, faded or skewed scans, unusual fonts, or when you see garbled characters in the output. * **`tables.agentic`** — reviews and fixes table structure. Enable for tables with misaligned columns, merged cells, or values landing in the wrong column. Clean, simple PDFs may parse accurately without it — test your document types with it off first, then enable it selectively. ```json { "config": { "blockOptions": { "text": { "agentic": { "enabled": true } }, "tables": { "agentic": { "enabled": true } } } } } ``` See [Text](/parsing/configuration#text) and [Tables](/parsing/configuration#tables). --- ## Performance optimization Parse defaults favor accuracy. Adjust these settings to trade some accuracy for speed and cost, or the reverse. **For fastest, lowest-cost processing:** | Setting | Why it helps | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `blockOptions.text.agentic.enabled: false` | Skips VLM-based OCR correction — the single biggest latency saver. | | `blockOptions.figures.enabled: false` | Skips figure classification and summarization. | | `advancedOptions.pageRotationEnabled: false` | Skips rotation detection when pages are already upright. | | `chunkingStrategy.type: "page"` or `"document"` | Avoids the extra work of computing semantic sections. | | `engine: "parse_light"` | Faster, lower-cost engine for high-volume ingestion; still handles layout well, with some accuracy trade-off on hard scans, handwriting, large tables, and dense checkboxes. | **For highest accuracy:** | Setting | Why it helps | | ---------------------------------------------------------- | -------------------------------------------------------------- | | `engine: "parse_performance"` | Best handling of complex layouts, tables, and scans (default). | | `target: "markdown"` + `chunkingStrategy.type: "section"` | Clean reading order with complete semantic chunks. | | `blockOptions.text.agentic.enabled: true` | Corrects low-confidence OCR and handwriting. | | `blockOptions.tables.tableHeaderContinuationEnabled: true` | Repeats headers across multi-page tables. | | `blockOptions.text.signatureDetectionEnabled: true` | Detects signatures in legal documents. | **For mixed-complexity workloads:** if your documents range from simple digital PDFs to dense scans and you don't want to pick an engine per document, use `engine: "parse_auto"` (Beta). It routes work per page — simple pages get light-level cost and speed, while complex pages automatically get performance-level treatment. You're billed per page by complexity (0.5–2 credits per page); see [How Credits Work](/general/how-credits-work#base-pricing-auto). --- ## Troubleshooting | Symptom | What to try | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | Poor OCR or garbled text | Enable `blockOptions.text.agentic.enabled`; try `target: "spatial"` for very messy or skewed scans. | | Chunks are too large or too small | Tune `minCharacters` / `maxCharacters` on `section` chunking, or switch the chunking `type` (`page` / `section` / `document`). | | Tables look broken | Set `blockOptions.tables.targetFormat: "html"`; enable `tableHeaderContinuationEnabled` for multi-page tables. | | Processing is too slow | See [Performance optimization](#performance-optimization). | | Large document times out | Move off the synchronous endpoint — see [Move to production with async processing](#move-to-production-with-async-processing). | --- ## Recipes Ready-to-run `config` blocks for common scenarios (comments added to explain each setting). For field-level options and defaults, see [Configuration](/parsing/configuration). ### Optimized for a RAG pipeline ```json { "config": { "target": "markdown", "chunkingStrategy": { "type": "section", // complete semantic units to embed and retrieve "options": { "minCharacters": 500, "maxCharacters": 10000 } }, "blockOptions": { "figures": { "enabled": true, "figureImageClippingEnabled": false }, // summarize charts/diagrams, skip image exports "tables": { "targetFormat": "html" } // preserve complex table structure } } } ``` ### Low-latency, cost-optimized ```json { "config": { "target": "markdown", "chunkingStrategy": { "type": "page" }, // skip semantic section computation "blockOptions": { "figures": { "enabled": false }, // skip figure analysis (latency + credits) "tables": { "targetFormat": "markdown" }, // lighter than html "text": { "signatureDetectionEnabled": false, "agentic": { "enabled": false } } // skip VLM OCR correction }, "advancedOptions": { "pageRotationEnabled": false } // skip rotation detection when pages are upright } } ``` ### Mixed-complexity ingestion ```json { "config": { "target": "markdown", "engine": "parse_auto", // routes each page to light or performance treatment by complexity "chunkingStrategy": { "type": "page" }, "blockOptions": { "tables": { "targetFormat": "html" } // preserve structure when complex pages contain tables } } } ``` ### Complex legal documents ```json { "config": { "target": "markdown", "chunkingStrategy": { "type": "section" }, "blockOptions": { "figures": { "enabled": true, "figureImageClippingEnabled": true }, "tables": { "targetFormat": "html", "tableHeaderContinuationEnabled": true }, // keep headers on multi-page tables "text": { "signatureDetectionEnabled": true, "agentic": { "enabled": true } } // catch signatures + fix tricky text } } } ``` ### Handwritten forms ```json { "config": { "target": "spatial", // preserve layout when reading order is unreliable "chunkingStrategy": { "type": "page" }, "blockOptions": { "figures": { "enabled": false }, "text": { "signatureDetectionEnabled": true, "agentic": { "enabled": true } } // VLM correction for handwriting } } } ``` --- ## Move to production with async processing The quick start and the examples above use the synchronous `/parse` endpoint — the fastest way to try Parse and iterate on config. When you're ready to run Parse in production, switch to the asynchronous `/parse_runs` endpoint. **Why the sync `/parse` endpoint isn't built for production:** * It has a **5-minute timeout** — large or complex documents can exceed it and fail. * It holds a connection open for the entire parse, which is brittle for big files and bursty traffic. * There's no delivery mechanism — you can't receive a webhook when the run finishes; you only get the result if the request stays open. * It's intended for onboarding and testing, not sustained workloads. **What async (`/parse_runs`) gives you:** * Reliable handling of large documents without timeouts. * Results via polling (`GET /parse_runs/{id}`) or webhooks, so you're not holding connections open. * A better fit for batch and high-volume pipelines. See [Async Processing](/general/async-processing) for the full comparison, polling options, and webhook setup.