Most guides tell you which services support markdown. None of them tell you what markdown costs. On both hyperscalers it is not an output setting on the cheap meter, it is a different, more expensive model: $1.50 per 1,000 pages becomes $10.00. Every capability claim below was read off the vendor's own documentation in August 2026.
Upload a document to extract
Drop files here or click to upload
Up to 50 files
Free plan extracts the first 5, rest can be unlocked after
Uploading...
Reading order on a two-column scan is where these services actually differ. Drop in your hardest page rather than your cleanest one.
If the PDF has a real text layer, a local library converts it for free and you should stop there. If the PDF is a scan, there is no text to convert and you need an OCR service that outputs markdown. Mistral OCR 4 and Amazon Bedrock Data Automation return markdown by default, Azure AI Document Intelligence returns it when you set outputContentFormat=markdown on the Layout model, and LlamaParse, Reducto and Landing AI ADE all produce markdown. AWS Textract and Google Document AI publish no markdown output format at all.
The three cheapest recognition meters in the industry, Azure Read, AWS Textract and Google Enterprise Document OCR, all cost $1.50 per 1,000 pages and none of the three returns markdown.
Moving to a markdown-capable meter on either hyperscaler costs $10.00 per 1,000 pages. That is the number missing from every "top 10 PDF to markdown tools" article.
Every row below states the vendor's own position from its own documentation, read in August 2026. The rate column is the meter you actually land on when you ask for markdown, not the vendor's cheapest headline price.
| Service | Markdown output | How you get it | Per 1,000 pages |
|---|---|---|---|
| Azure AI Document Intelligence (Read) | No | Read returns text and JSON. Markdown is not a Read feature. | $1.50 |
| Azure AI Document Intelligence (Layout) | Yes | outputContentFormat=markdown | $10.00 |
| AWS Textract (all operations) | No | Returns a list of Block objects as JSON. No markdown in any operation. | $1.50 |
| Amazon Bedrock Data Automation | Yes, by default | "Text with markdown" is the default standard output text format | $10.00 |
| Google Document AI (Enterprise Document OCR) | No | Returns the Document JSON object. | $1.50 |
| Google Document AI (Layout Parser) | No published markdown format | Returns a DocumentLayout tree and chunks. | Billed separately |
| Mistral OCR 4 | Yes, natively | markdown is the main output field on every page | $4.00 |
| Mistral Document AI | Yes, plus JSON fields | Same markdown, plus annotations against your schema | $5.00 |
| LlamaParse | Yes | result_type="markdown" | $1.25 to $12.50 by tier |
| Reducto (standard parse) | Yes | Markdown is the parse output format. | $15.00 |
| Landing AI ADE (v2 async standard) | Yes | Markdown parse output. | $5.00 |
| Unstructured.io | Element JSON, not markdown | Partitions into elements for chunking. | $30.00 |
Azure AI Content Understanding is deliberately absent. Its documentation describes text, tables, sections and LaTeX formulas but does not state a markdown output format, and we do not publish a capability we have not read in the vendor's own docs. Rates for the underlying meters are broken down on OCR pricing per 1,000 pages.
Textract's response model is a flat list of Block objects linked in parent-to-child relationships: pages, lines, words, key-value pairs, tables, cells, selection elements, queries and layout blocks, each with a bounding box and a confidence value. It is a graph, not a document. Rendering it as markdown means walking the relationships yourself and deciding what a heading is.
AWS's answer is Bedrock Data Automation, which does that work for you and returns representation.markdown on every entity, at document, page and element level. The full rate breakdown sits on Amazon Bedrock Data Automation pricing, and the two services are compared directly on Bedrock Data Automation vs Textract.
Microsoft documents markdown as a Layout capability: the Layout API can output the extracted text in markdown format when you pass outputContentFormat=markdown. Read, the $1.50 meter, does text and JSON. Layout, the meter that understands sections, tables and reading order well enough to write markdown at all, is $10.00 per 1,000 pages.
That is a defensible price for what Layout does. It is only surprising if you budgeted from the Read rate. The meter-by-meter breakdown is on Azure Document Intelligence pricing, and the renamed-entity history is on Azure Form Recognizer pricing.
Two services can both claim markdown output and hand you files that need completely different downstream code. Tables are where they diverge hardest, because standard markdown has no syntax for a merged cell.
Full <table>, <tr>, <th>, <td> markup rather than pipe tables, so merged cells survive as rowspan and colspan and captions survive as <caption>.
Selection marks become ☒ and ☐. Formulas become LaTeX in $...$ and $$...$$. Barcodes become image syntax with the decoded value. Page headers, footers and numbers are hidden in HTML comments, and pages are split by <!-- PageBreak -->.
table_format takes null for tables inline in the page markdown, "markdown" to get them back as a separate list, or "html" for HTML tables.
Images and tables are written into the markdown as placeholders such as  and [tbl-3.html](tbl-3.html). You have to map them from the images and tables arrays or they render as nothing.
Each table entity carries four representations at once, so you can keep the markdown for the model and the CSV for the spreadsheet.
Every entity has representation.markdown at document, page and element level. Word-level granularity drops the formatting and returns positions only.
Table formatting is configurable, including an option to emit HTML instead.
Higher parsing tiers produce higher fidelity output. The cheapest tier is the one to test first if your documents are simple digital PDFs.
<!-- PageHeader="Quarterly Report" -->
## Revenue by segment
<table>
<caption>Table 1. Segment revenue</caption>
<tr><th>Segment</th><th>Q1</th><th>Q2</th></tr>
<tr><td>Cloud</td><td>1,204</td><td>1,388</td></tr>
</table>
Audited ☒ Unaudited ☐
The margin identity $m = \frac{r - c}{r}$ holds per segment.
<!-- PageFooter="Confidential" -->
<!-- PageNumber="4" -->
<!-- PageBreak -->
Every element in that block is documented behavior, not an approximation: HTML tables with captions, Unicode selection marks, LaTeX formulas, page furniture in HTML comments and an explicit page-break delimiter. If your chunker splits on ## and expects pipe tables, it will silently mangle this.
On Azure, markdown is a Layout model feature, and Layout is $10.00 per 1,000 pages against $1.50 for Read. On AWS, Textract has no markdown output at all, so markdown means Bedrock Data Automation at $10.00 per 1,000 pages against Textract at $1.50. Both clouds charge about 6.7 times more for the same words in a different wrapper.
Azure emits HTML tables inside its markdown on purpose, because standard markdown pipe syntax cannot express a merged cell or a multirow header. If your chunker assumes GitHub-flavored pipe tables, Azure output and Mistral in html mode will not parse the way you expect.
Mistral writes  into the markdown and returns the actual image in a separate array. Save only the markdown string and every figure in the document resolves to a broken link. The same applies to its [tbl-3.html] table placeholders.
Microsoft documents it plainly: key-value pairs, language and style are mapped to the JSON body and not into the markdown content. If you paid for a model that finds key-value pairs and then keep only the markdown, you threw the key-value pairs away.
pdfminer, pdfplumber, PyMuPDF, pandoc and Microsoft MarkItDown all read the embedded text layer. A scan has no text layer, so they return an empty or near-empty file. Converting a scanned PDF to markdown requires OCR, which is why the markdown-capable services above are priced per page.
Markdown is text. There is no field in it to tell you the model was unsure about a number. If you need to gate a review queue, you need the JSON response alongside the markdown, and you need a service that returns per-value confidence at all.
Most teams get this wrong by picking a vendor first and discovering the meter afterwards. Work through it the other way round and the bill stops surprising you.
If your documents are a mixed pile of digital PDFs and scans, split them at ingest. Running clean digital PDFs through a paid recognition API is the single most common way to overpay, and it is invisible on the invoice because the pages look identical.
Open it and try to select a sentence. If the text highlights, a library can read it and you may not need OCR at all. If it does not, the page is an image and you need a recognition service.
On Azure that means Layout rather than Read. On AWS it means Bedrock Data Automation rather than Textract. On Mistral and LlamaParse markdown is the native output, so there is no second meter to move to.
This is where output quality is won or lost. Choose HTML tables if your documents have merged cells, and plan to resolve image placeholders back to files if you want figures to survive.
Store both. The markdown is what you feed the model. The JSON holds the confidence values, the bounding boxes and the key-value pairs, and you will want them the first time an extracted number is wrong.
A scanned page is a photograph of text. There are no characters in the file, so a text-layer library has nothing to read and returns an empty document. This catches people out because the failure is silent: the script runs, the markdown file is created, and it is blank or contains only the page numbers that happened to be typed rather than scanned.
Microsoft's MarkItDown is the usual place this shows up, because it is fast, free and widely recommended for LLM pipelines. It converts PDFs through pdfminer and pdfplumber, both of which read embedded text only. Its README does list OCR under images, but the image converter as shipped extracts EXIF metadata and, when you configure an LLM client, an LLM-written description of the picture. A description of a page is not a transcription of it. We walked through the source in does MarkItDown do OCR.
Once you accept that scans need recognition, the choice becomes a pricing question again, and the answers are on the OCR API pricing comparison.
| Tool | Result on a scanned page |
|---|---|
| MarkItDown | Empty or near-empty markdown. Reads the text layer through pdfminer and pdfplumber. |
| pymupdf4llm | Empty markdown. Same text-layer limitation. |
| pandoc | Not applicable. It converts between markup formats, not from images. |
| Mistral OCR 4 | Full markdown, plus confidence scores and block bounding boxes. |
| Azure Layout | Full markdown with HTML tables, at the $10.00 meter. |
| Bedrock Data Automation | Full markdown, plus HTML, text and CSV of each table. |
Markdown-capable meters only, normalized to the same unit. This is the table to take into a budget conversation, because the spread between the cheapest and the most expensive row is 15 times.
| Service | Per 1,000 pages | 100,000 pages | Notes |
|---|---|---|---|
| Mistral OCR 4 | $4.00 | $400 | Markdown native, with confidence scores and block bounding boxes in the same response. |
| Mistral OCR 4 (batch) | $2.00 | $200 | Batch halves the rate. The cheapest markdown-capable cloud rate we can verify. |
| Landing AI ADE v2 (async standard) | $5.00 | $500 | Credit-priced. Zero data retention is free on v2. |
| Azure AI Document Intelligence (Layout) | $10.00 | $1,000 | HTML tables, LaTeX formulas, page-break markers. |
| Amazon Bedrock Data Automation | $10.00 | $1,000 | Markdown, HTML, text and CSV of every table, in one response. |
| LlamaParse (cost-effective tier) | $3.75 | $375 | Credit-priced at 3 credits per page. The agentic tier is $12.50. |
| Reducto (standard parse) | $15.00 | $1,500 | One credit per page at $0.015 per credit. |
| Unstructured.io | $30.00 | $3,000 | Elements for chunking rather than a markdown document. |
Mistral, Anthropic and OpenAI discount batch work by about 50%. AWS, Azure and Google publish no batch discount on these meters, so an overnight job costs the same as a real-time one. Volume behavior across every vendor is on high volume OCR APIs, and the credit-priced tier is normalized on agentic document extraction pricing.
Markdown is excellent for retrieval. You are feeding a model a readable document, and headings, lists and tables give it structure it already understands. For that job it beats a verbose layout JSON that spends most of the context window on coordinates.
It is the wrong output when what you need is a record. If the deliverable is an invoice number, a date, twelve line items and a total landing in your accounting system, a markdown file has moved the problem rather than solved it: you still have to find the fields, and now you are parsing text instead of reading a typed response. Worse, markdown carries no confidence value, so you cannot route the uncertain ones to a person.
That is the split worth naming before you choose. Markdown for reading. Typed fields with confidence for posting. If you need the second, look at PDF to JSON extraction and PDF data extraction instead.
Retrieval, search indexes, feeding whole documents to a model, anything a human or a model reads end to end.
Posting to an ERP, reconciling totals, anything where a wrong number has a consequence.
Keep the markdown for context and the JSON for the values, coordinates and confidence. Storage is cheaper than a second extraction run.
Whatever the format, you need a screen where a person fixes the values that came back uncertain.
If the PDF has a text layer, a library such as pdfminer, PyMuPDF or Microsoft MarkItDown can convert it locally in one line of code and cost you nothing. If the PDF is a scan, the page is an image and there is no text to convert, so you need an OCR service that returns markdown: Mistral OCR, Azure Document Intelligence Layout, Amazon Bedrock Data Automation, LlamaParse, Reducto or Landing AI.
Mistral OCR 4 and Mistral Document AI return markdown natively as the main output field. Azure AI Document Intelligence returns markdown when you set outputContentFormat=markdown on the Layout model. Amazon Bedrock Data Automation returns markdown by default. LlamaParse, Reducto and Landing AI ADE all return markdown. AWS Textract and Google Document AI do not publish a markdown output format.
No. Amazon Textract returns a document as a list of Block objects in JSON, covering pages, lines, words, key-value pairs, tables, selection elements, queries and layout. There is no markdown output in any Textract operation. On AWS the markdown answer is Amazon Bedrock Data Automation, where markdown is the default text format for standard document output.
Yes, on the Layout model. Set outputContentFormat=markdown and the extracted content comes back as markdown in the content field. Note that this is a Layout feature, so the cheaper Read model does not offer it. Azure emits tables as HTML inside the markdown rather than as pipe tables, so merged cells and captions survive.
It depends entirely on which meter you land on. Mistral OCR 4 is $4.00 per 1,000 pages, or $2.00 in batch. Azure Layout and Amazon Bedrock Data Automation are both $10.00. LlamaParse runs from $1.25 on its fastest tier to $12.50 for agentic parsing, Landing AI ADE v2 async standard is $5.00, Reducto standard parse is $15.00 and Unstructured.io is $30.00.
Because on both hyperscalers markdown lives on a different model. Plain recognition on Azure Read, AWS Textract and Google Enterprise Document OCR is $1.50 per 1,000 pages, and none of the three returns markdown. Getting markdown means Azure Layout or Amazon Bedrock Data Automation, both $10.00. You are paying for layout analysis, reading order and table structure, not for the markdown characters.
For a digital PDF, pip install pymupdf4llm or markitdown and call one function. For a scanned PDF, call an OCR API from Python and read the markdown out of the response: with Mistral that is client.ocr.process(), and the markdown sits in response.pages[i].markdown. With Azure, pass output_content_format=ContentFormat.MARKDOWN to begin_analyze_document and read result.content.
Yes, but only with OCR. A scanned page is a picture of text with no character data behind it, so text-layer libraries return an empty file. Send the scan to a recognition service that outputs markdown, and check the output on your worst document rather than your cleanest one, because reading order on a multi-column scan is where these services differ most.
Not on PDFs. Microsoft MarkItDown converts a PDF using pdfminer and pdfplumber, which read the embedded text layer only, so a scanned PDF produces an empty result. Its README lists OCR under images, but the shipped image converter extracts EXIF metadata and, if you configure an LLM client, an LLM-written description of the picture. A description is not character recognition.
Choose a service that returns the image bytes or a URL alongside the markdown, then rewrite the placeholders. Mistral writes  into the markdown and returns the image in the images array. Azure wraps figures in <figure> and <figcaption> tags. Bedrock Data Automation writes cropped figure images to your S3 bucket and references them from the entity.
Markdown is close to plain text, so it is token-efficient, and headings, lists and tables survive as structure the model already understands from its training data. A verbose layout JSON spends a large share of the context window on coordinates. The tradeoff is that markdown drops confidence values and key-value pairs, which is why production pipelines keep both.
Yes, and this is where the per-page rate starts to matter. Mistral, Anthropic and OpenAI all discount batch work by about 50%, so a large overnight markdown job on Mistral OCR runs at $2.00 per 1,000 pages. AWS, Azure and Google publish no batch discount, so 100,000 pages through Azure Layout or Bedrock Data Automation costs $1,000 either way.
Usually not on its own. Markdown gives you a readable document, not a record. If what you actually need is the invoice number, the date, the line items and the total landing in your accounting system, you want structured field extraction with confidence values and a review step, and the markdown becomes a byproduct rather than the deliverable.
For digital PDFs with a real text layer, a local library costs nothing beyond your own compute and is genuinely the right answer. For scans, Mistral OCR 4 in batch at $2.00 per 1,000 pages is the cheapest markdown-capable cloud rate we can verify, and LlamaParse fast tier is $1.25 per 1,000 pages on credits. Both leave you to build everything around the recognition step.
What the source actually does with a scanned PDF, and what to use when it returns nothing.
The markdown-native document model, with its full response spec and both published rates.
When you need typed fields and confidence values rather than a readable document.
The hardest part of any markdown conversion, handled on its own terms.
Every vendor normalized to one unit so the meters can be compared directly.
File sizes, page ceilings and retention windows across every major service.
The AWS meter that does return markdown, priced in full.
Working code for calling a recognition service from Python.
The wider developer reference for turning pages into text.
Where a document model beats prompting a chat model, and why confidence is the reason.
What changes at 100,000 pages a month and above.
The buying decision rather than the rate card.
Every service on this page will hand you a plausible markdown file from a clean page. The differences show up on a two-column scan with a merged-cell table. Upload that one.
Markdown capability claims on this page were read from each vendor's own documentation on 13 August 2026. Rates are the per-1,000-page figures published by each vendor and re-verified across earlier reviews. Capabilities and rates change. Verify at the source before you sign anything.