ragconverter.com vs Marker: PDF to a RAG corpus
ragconverter.com and Marker both aim at documents a language model will read. Marker converts PDFs to Markdown on a machine you run, and is built for difficult papers. RAG Converter converts in the browser with no install, and its API returns chunked embeddings as JSONL for a pipeline.
How does ragconverter.com compare with Marker?
Marker turns PDFs into Markdown on a machine you run, which suits difficult papers when you can host the model. ragconverter.com turns a document into embedded JSONL in the browser with no install, and offers the same conversion as an API for pipelines.
A PDF-to-Markdown converter, run locally
Marker converts PDFs to Markdown, with a reputation for multi-column papers, equations, and pages that flatten badly under a plain text extract. You run it on your own hardware. A GPU is what makes a large corpus practical; a CPU will finish, slowly. The repository code is Apache-2.0. The model weights ship under a separate license with limits on commercial use, so read that file before Marker sits inside a product. The output is Markdown. Chunking and embeddings are the tools you add next.
Localization without a Python environment
Marker's local path is a real one: the PDF stays on the machine that has the weights. It asks for an install, a GPU if you have one, and someone who will keep that environment working. ragconverter.com's local path is the tab. A text-layer PDF, a Word file, a slide deck, or a spreadsheet converts with no upload and no install, under a browser budget - 8 MB and 400 chunks on the free tier, more once you are signed in, and still inside WebAssembly's 4 GB address space. That is the right localization when the reader of the document is not going to set up PyTorch. The limits are spelled out in local RAG in the browser.
A hosted parse, and a RAG API
Datalab, the company behind Marker, also offers a hosted conversion API. Using it means the PDF is uploaded, and the thing you get back is still a parse you then chunk and embed. ragconverter.com's API is aimed at the step after a parse: POST the file to /v1/convert and the response is NDJSON, one passage per line, with the embedding and the metadata a citation needs. The manifest says which model embedded the text and which files were skipped. Video and full-resolution OCR live on that API because a tab cannot do them. The contract is the one in a RAG conversion API for developers.
Hard PDFs are Marker's argument
A scientific PDF with equations and a two-column layout is the document Marker is arranged around. If that is your corpus, convert a sample with Marker and read the Markdown before you decide a general converter is enough. ragconverter.com keeps heading structure, keeps tables out of the surrounding prose, and emits passages sized for a sentence embedding rather than for an LLM context window. It will not beat a specialist on LaTeX-heavy pages, and the article on PDF to Markdown for LLMs is the failure mode to look for: valid Markdown whose reading order is wrong.
Pick by the artifact you need
Choose Marker when the PDF itself is the hard problem, you can run the model, and the weights license fits how you ship. Choose ragconverter.com when the artifact you need is a RAG corpus - chunks, embeddings, page and heading metadata - and the person with the file should be able to produce it without an install. Choose the API when that same corpus has to be produced unattended. The passage text is in the JSONL if you later swap the encoder. The implementation behind the tab and the server is Remade with Rust.