ragconverter.com vs Unstructured: browser and API
ragconverter.com and Unstructured both turn documents into pieces a RAG pipeline can index. Unstructured is an open-source library you install, plus a separate hosted platform. RAG Converter converts in the browser with no install, and offers the same JSONL from an API when the job has to run on a server.
How does ragconverter.com compare with Unstructured?
ragconverter.com keeps one conversion for the browser and the API, and both return chunked JSONL with embeddings. Unstructured is an open-source partitioning library you install, plus a hosted platform for pipelines that should run as a service rather than on a laptop.
A library and a platform, sold as one name
Unstructured ships an open-source library that partitions documents into elements, with chunking strategies aimed at retrieval, and a hosted platform that runs pipelines, connectors, and the models the open-source path does not include. Treat those as two products. The library is what you operate. The platform is what you call. ragconverter.com is one conversion: the tab and /v1/convert emit the same chunk objects, and the manifest records which embedder ran and what a limit cut.
What local means for each
Local, for the Unstructured library, means a Python environment on a machine you administer. That is a genuine no-upload path, and it is the right one for a team that already runs its own workers and wants the partitioning code in-process. Local, for ragconverter.com, means the visitor's browser. There is no install, no virtualenv, and no process to keep up. Someone with a folder of contracts can convert them on the machine where the files already are. Local RAG in the browser is the longer note on what that runtime can hold and where it runs out.
What you actually call
Unstructured's platform is an ETL product: sources, workflow steps, and destinations into vector stores. That is valuable when the corpus lives in systems you want connected, and it is a larger surface than a conversion. The ragconverter.com API is one multipart POST. Bytes in, NDJSON out, one JSON object per passage, embeddings included, failures named per file so a bad PDF does not abort the other ninety-nine. You keep the loader. They do not become your orchestration layer. Details sit in a RAG conversion API for developers.
File coverage is not the same question as the artifact
Unstructured's pitch is breadth: many file types, element metadata, and a connector catalog. Measure that on your files, because the open-source library and the paid platform are different extraction tiers, and a README count of formats will not tell you which tier you are on. ragconverter.com is explicit about the text-layer formats it reads cleanly - PDF, Word, PowerPoint, Excel, Markdown, HTML, CSV - and about images, scans, audio, and video, which need OCR or transcription and, for video, the API. A wide catalog that silently emits empty passages is a worse corpus than a shorter one that names the skip.
Which one to start with
Start with Unstructured when you want their workflow product, their connectors, or the library linked into a Python service you already deploy. Start with ragconverter.com when the first conversion should happen without an install and without an upload, and the later conversion should be the same JSONL from an API. The passage text is in the object either way, so a pipeline with its own embedding model can ignore the vectors and keep the chunks. The stack behind that conversion is Remade with Rust.