Document ETL for RAG
unstructured is the ingest layer for retrieval pipelines: it takes the messy file types a real organization has, including PDF, DOCX, PPTX, HTML, and email, and turns each into a uniform list of elements such as Title, NarrativeText, Table, and ListItem. That element model is the point. Instead of a flat string, you get typed, structured pieces with metadata that you can chunk and embed for a RAG system. At 14,936 stars as of 2026-06, it is a common first choice for teams wiring documents into LangChain or LlamaIndex.
What it does
The main entry is a partition function that detects the file type and breaks it into elements. From there you chunk by title or token count and pass the result to an embedding step. It plugs directly into the popular RAG frameworks, and a separate ingest package adds connectors to sources like S3, MongoDB, and Snowflake, so it can be the front of a full pipeline rather than a one-file utility.
Install, and the dependency reality
This is where expectations meet reality. The base install is small, but real document support pulls in heavy system dependencies:
pip install "unstructured[all-docs]"The all-docs extra expects system packages like poppler, tesseract, and libmagic, and possibly libreoffice, which is the most common source of installation pain, especially on Windows. Many teams end up running it in Docker just to get the system dependencies right. Budget time for the environment, not just the pip line.
The open-source library versus the platform
The judgment that matters before you commit: unstructured is an open-source library and a commercial platform, and they are not the same product. The Apache-2.0 library gives you partitioning, element types, and basic chunking. The paid Unstructured Platform and API add managed processing, richer chunking and enrichment, image and table handling, and a low-code pipeline UI. Some capabilities and the smoothest experience live behind the commercial offering. That is a fair business model, but read the boundary so you are not surprised when a feature you assumed was in the library is actually a platform feature.
Where it fits, and where it doesn’t
Reach for unstructured when you are building a RAG ingest pipeline, when you value its connectors and framework integrations, and when the typed-element model fits how you chunk and retrieve. For a managed pipeline at scale, the platform is a real option.
It is heavier than you might want for a quick local conversion, the dependency setup is a known hurdle, and table extraction is fragile enough that you should verify tables that feed downstream logic. Large files can also consume surprising amounts of memory. If you want layout-aware local parsing without the platform angle, docling is worth comparing.
unstructured versus the other document tools
| unstructured | docling | markitdown | jina reader | |
|---|---|---|---|---|
| Stars | 14,936 | 61,641 | 152,764 | 11,235 |
| Model | typed elements for RAG | layout-aware parsing | lightweight conversion | URL to Markdown |
| Dependencies | heavy (poppler, tesseract) | moderate (models) | light | none (hosted) |
| Open vs paid | library plus paid platform | fully open (MIT) | fully open (MIT) | hosted plus self-host |
| Best for | RAG ingest with connectors | layout fidelity, local | quick office to Markdown | web pages |
Counts are from GitHub as of June 2026. docling is fully open and focuses on layout fidelity with local execution. markitdown is the lightweight converter. jina reader handles web URLs. unstructured’s edge is the RAG-native element model plus source connectors; its cost is dependencies and the library-versus-platform split.
The star curve
The star curve rose with the RAG wave, when document ingest became a universal need, and it tracks the rise of LangChain-style stacks it integrates with. The growth is steady rather than explosive, consistent with an infrastructure library that teams adopt deliberately rather than on hype.
What the issue tracker warns you about
The recurring pain is environmental and structural. Installation failures from missing system dependencies are the top complaint, which is why Docker is the common workaround. The hi_res strategy is slow and downloads a layout model on first use, while fast trades accuracy for speed, and choosing between them is not well signposted. Table extraction has had breaking changes and misclassifies some content, so do not trust tables blindly. And large or complex files, including big HTML and spreadsheets, can blow up memory. These are the realities of general document parsing, sharpened here by the dependency weight.
Related
For fully open, layout-aware local parsing, see docling. For lightweight conversion, see markitdown. For web pages, see jina reader. For the OCR engines behind document parsing, see Tesseract and PaddleOCR. For what is trending, see the daily digest and the weekly report.
FAQ
unstructured vs docling, which should I use? unstructured gives a RAG-native element model with source connectors and an open library plus a paid platform. docling is fully open and focuses on layout-aware local parsing. Choose unstructured for a connector-rich ingest pipeline, docling for layout fidelity and a fully open dependency.
Why is unstructured hard to install? Real document support needs system packages like poppler, tesseract, and libmagic, which the pip extra does not install for you. Missing these is the top cause of failures, and many teams run it in Docker to get the environment right.
Is unstructured free, or do I need to pay? The library is free under Apache-2.0. There is also a paid Unstructured Platform and API that add managed processing, richer enrichment, and a pipeline UI. Some capabilities live behind the commercial offering, so check which side a feature is on.
What is the difference between hi_res and fast strategies? hi_res uses a layout model for better accuracy but is slower and downloads a model on first use. fast is quicker and less accurate. Pick based on whether accuracy or throughput matters for your documents.
Can unstructured extract tables reliably? Partially. Table extraction works but has had breaking changes and misclassifies some content as tables, so verify any table that feeds downstream logic rather than trusting it blindly.