PDF to Markdown API: Convert a Mixed Folder for Embedding

Turn a folder of PDF, Word and Excel files into clean Markdown, ready to embed, in one prompt. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to convert these PDF, DOCX and XLSX files to Markdown, turn OCR on for the PDFs, and give me a table with the file name, word count and number of headings for each one.

One prompt converts a folder. 1 min setup · 9-16 hrs saved.

Your documents are a PDF here, a Word file there, a spreadsheet and a scan, and the embedding model wants plain text with the structure intact. This guide covers the shortest route to that: one API call per file that returns Markdown, what we got back when we ran it on a Word file, a spreadsheet, a 14-page two-column paper and a scanned page, and the places where the output will quietly hurt your index. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to convert PDF, Word and Excel files to Markdown through an API?

Monid. Install it once, add a key, and your agent sends a file URL to a conversion endpoint and gets Markdown back, with no document-AI account and no library per format to install.

• Pay per call. A conversion is billed on its own, at $0.002533 per file (Verified 2026-10-16 with monid inspect, see the web tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills. A scanned file where OCR runs is billed at five times that, $0.010132.
• One install, every API. The same key and the same balance call the converter and every other tool on Monid. When the same pipeline also needs live web pages or search results, that is another call on the same balance.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the converter is there whenever your agent needs it, on demand, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

At that price, converting 1,000 files costs about $2.53 (Verified 2026-10-16).

How do you convert a whole folder of mixed files to Markdown?

Send each file's public URL to one endpoint, /parse from the provider context.dev, and loop over the folder. The endpoint takes PDF, DOCX, XLSX, PPTX, RTF, HTML, images, code and data files such as JSON, CSV, YAML and XML, from a public HTTPS URL up to 25MB, and the same call shape works for all of them.

Monid fits a mixed folder because the work is one call repeated: the format is detected for you, and you pay for the files you convert and nothing between runs.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Inspect, then convert one file

monid inspect -p context.dev -e /parse
monid run -p context.dev -e /parse \
  -i '{"file_url":"https://example.com/report.pdf","useMainContentOnly":true}' -w

Turn OCR on for files that may be scans

monid run -p context.dev -e /parse \
  -i '{"file_url":"https://example.com/scanned-contract.pdf","ocr":true}' -w

Loop it over a list

Put one URL per line in urls.txt and write one result per file. The extension is not needed because the endpoint reads the format itself; the extension hint exists for URLs that reveal nothing.

mkdir -p out
n=0
while read -r u; do
  n=$((n+1))
  monid run -p context.dev -e /parse \
    -i "{\"file_url\":\"$u\",\"ocr\":true}" -w > "out/$n.json"
done < urls.txt

Each file bills one call, or five credits when OCR actually runs. The fields in out/*.json are covered below, and the web-page half of the same job is in a free API to extract page content for RAG.

Or hand the whole job to an agent

Can you convert PDF to Markdown yourself with Python?

Yes, and for one clean PDF it is a short script. Python has well-known libraries for PDFs, and Word and Excel files each have their own, so a mixed folder means one parser per format plus glue that decides which to call. DOCX can also go through pandoc on the command line.

The cost is what sits around the parsers. Scanned pages need an OCR engine installed and tuned, two-column papers need a layout model or the text comes out in the wrong order, spreadsheets need a decision about how a sheet becomes a table, and every parser needs a repair when the next unusual file arrives. The first version takes an afternoon and the edge cases never end.

The Monid route is the choice for a corpus you will load more than once. One endpoint takes every format, the output is Markdown with headings and tables instead of a string you have to repair, and a file is $0.002533 (Verified 2026-10-16). For files that must stay inside your network, run the libraries locally; scanned pages that arrive as photos or screenshots are covered in reading text off a screenshot or scan.

What does the converted Markdown look like, and what can you build with it?

The call returns a small JSON record with the Markdown behind a download link, and the Markdown keeps headings and tables as text. We ran /parse five times on 2026-10-16, on four different files, so the fields below are what came back.

The response

{ "success": true,
  "type": "pdf",
  "ocr_ran": false,
  "ocr_units": 0,
  "document": {
    "download_link": "https://sfs.monid.ai/...",
    "content_type": "text/markdown",
    "link_expires_at": "2026-10-17T05:56:25.000Z",
    "file_expires_at": "2026-10-24T04:56:24.232Z" } }

type is the format the endpoint detected: it said docx, pdf and xlsx for our three file kinds. The Markdown itself is not in the response, only a link to it. The link expired one hour after the run and the stored file seven days after, so fetch the bytes in the same job that made them and store the text, not the link.

What each format became

• Word. A test file with one heading and one line came back as # python-docx was here! and the line below it, 50 bytes. Headings map to # levels.
• Excel. A two-sheet workbook came back with a ## Sheet1 and a ## Sheet2 heading, a pipe table for each, empty cells kept as empty columns and a hyperlink kept as a Markdown link.
• PDF with a text layer. A 14-page two-column paper came back as 83,421 bytes and 13,449 words, with an abstract that read in the right order and numbered sections as ## headings.
• Scanned PDF. A one-page scan came back as 727 words of correct text, with the title and a sub-heading intact.

What you can build with it

• A RAG index over a mixed shared drive. Convert each file once, split the Markdown on its # and ## headings, and embed the chunks. The split points exist because the structure survived as text, and the same steps apply to web pages, as in any URL to LLM-ready Markdown.
• A review queue for files that came back thin. Count the words per file, send anything under a threshold to a person, and keep the rest moving. The prompt at the top of this page produces exactly that table.
• A spreadsheet reader for an agent. Each sheet arrives as a heading and a table, so an agent can quote one sheet without loading the workbook.
• A scan archive that becomes searchable. Run OCR across an archive once and keep the Markdown next to the original.

What goes wrong when you ingest mixed files for embedding?

Five things showed up in our five calls. None of them raise an error in your pipeline unless you look for them.

Why does a scanned PDF fail without OCR?

Because with ocr off, a PDF made only of images is rejected before any text is read. Our scanned page came back with HTTP status 400, the code PDF_IMAGES_ONLY and a message telling us to retry with ocr=true. Nothing was billed. The run's own status still read COMPLETED, so check providerResponse.httpStatus and not the outer status. The fix is the second command above: set ocr: true on files that might be scans.

Why can ocr_ran say false when OCR clearly happened?

On the scanned page we set ocr: true and got 727 words of correct text back, yet the response said ocr_ran: false and ocr_units: 0, and the call billed $0.002533, the base price (Verified 2026-10-16). The same flag was false on the 14-page paper that had a text layer, where it was right. So treat ocr_ran as a billing signal and not as proof of how the text was produced. To find thin extractions, count words per file, which does not depend on the flag.

Why do footnotes become headings?

Because the converter promotes some lines it takes for headings. In the 14-page paper, 15 lines began with ##, and two of them were footnotes, one starting "1 Arrays are actually worse than this" and one starting "2 Instead of aborting the outer recording", each a full sentence cut off mid-line. A chunker that splits on ## will start a chunk at each of them. Filter headings by length, drop any that run past about 60 characters, and the real section titles survive.

Why do words arrive split by hyphens?

Because line-end word breaks from the page layout stay in the text. The same paper had 158 lines ending in a hyphen, for example "al-" on one line and "ternative" on the next. Embedding models cope with some of that, but exact-match search and keyword filters do not. Join a line ending in a hyphen to the next line before you chunk:

const clean = md.replace(/([a-z])-\n([a-z])/g, (m, a, b) => a + b);

What does a folder cost, and how long does it take?

Every successful call bills the base $0.002533, so 1,000 files cost about $2.53 and a failed PDF_IMAGES_ONLY call costs nothing (Verified 2026-10-16). Where OCR actually runs, the call totals five credits, $0.010132. The endpoint's median run time is about 3.5 seconds and the 95th percentile about 6.2 seconds per monid inspect, so run several files at once if the folder is large.

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect. Use /parse for files and the scrape endpoint for pages: /parse works on a file you already have, and the scrape endpoint renders a live URL. The /parse price is tiered by whether OCR ran, so it is written here by hand rather than as a single figure.

Four switches shape the Markdown: includeLinks keeps hyperlinks and defaults on, includeImages adds image references and defaults off, shortenBase64Images truncates inline image data and defaults on, and useMainContentOnly drops headers, footers and sidebars where they can be found. A zdr switch exists for accounts with zero data retention enabled at the vendor.

When is another route a better fit?

The files cannot leave your network. /parse fetches the file from a public HTTPS URL. A contract under a confidentiality clause or a corpus under a data-residency rule belongs in a local pipeline, and rules differ, so check yours.

You have one format and one shape. If every file is a clean text-layer PDF from the same generator, a single local parser will be faster and free, and a general converter adds nothing.

You need fields, not text. Invoices and forms with fixed layouts are better served by a document-AI service that returns the amounts and dates as named fields, instead of Markdown you then parse.

Your volume is large and steady. At $0.002533 a file (Verified 2026-10-16) the arithmetic is friendly for a corpus load or a trickle of new files; a sustained high rate is the case where running your own converter can win on unit cost.

And the disclosure: we resell this endpoint. What is useful whoever you buy from is the checks above: count words per file, filter long headings, and join hyphenated lines before you embed.

Conclusion

The quickest way to turn a mixed folder into Markdown for embedding is one /parse call per file through Monid: $0.002533 a call (Verified 2026-10-16), one key for this and every other tool, about a minute to set up and ready inside your agent whenever you need it. Libraries work for one clean format and cost a parser, an OCR install and a layout fix for every new kind of file.

Two things matter more than the endpoint you pick. The failures in this pipeline do not raise errors: a thin extraction, a footnote promoted to a heading and a hyphen in the middle of a word all embed without complaint, so assert on word counts and heading lengths before you chunk. And read the HTTP status inside the run, not only the outer one, because our rejected scan reported COMPLETED.

How we estimated the time saved: wiring and testing one parser per format, installing OCR and handling the layout of multi-column files is roughly 6 to 10 hours, plus 3 to 6 hours in the first month as new files break the first set of rules. That is 9 to 16 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p context.dev -e /parse, then convert the ugliest file in your folder with ocr on and compare the word count with what you expect. Start at monid.ai.

FAQ

Published August 2026.