Streamlining Data Prep: Cloud vs. Local PDF to Markdown for Generative AI

Published: 2025-06-01 · Last updated: 2025-06-01 Author: [Author Name], Content Engineering · Technical reviewer: [Reviewer Name], ML Infrastructure Target keyword: PDF to Markdown (cloud vs. local) Meta description: Cloud vs. local PDF to Markdown conversion for generative AI: privacy, cost, throughput, structure fidelity, setup, and file limits — with sourced figures and a decision map.

Disclosure: The author has no paid, affiliate, or sponsorship relationship with any tool named in this article. Every tool referenced is either an open-source project or a commercial service with publicly published documentation. Prices and limits cited are list values retrieved on 1 June 2025 and change frequently — verify them on the vendor's own pricing or quotas page before you commit budget or architecture. Where no authoritative published figure exists, this article says so explicitly instead of implying one.

The short answer: for confidential, regulated, or proprietary PDFs, local (on-device) PDF to Markdown conversion is the safer default; for high-volume batch jobs and teams that want zero local setup, cloud (hosted) conversion is the better default — and most mature AI pipelines end up using both. From here on, "local (on-device)" means the document is parsed on hardware you control — a laptop, workstation, browser tab, or self-hosted server — and the source file never traverses a third-party network.

PDF to Markdown conversion exists because feeding raw PDFs into an LLM wastes tokens and destroys structure. Converting first is a standard preprocessing step for generative AI workflows: structure-aware Markdown keeps headings, lists, and tables intact, produces chunks that are ready for retrieval-augmented generation (RAG), and gives the model a format it parses more reliably than a flattened PDF text stream. The token economics are covered in detail in the next section, including why the commonly repeated numbers deserve a caveat.

The remaining question is where that conversion happens. This article compares cloud and local (on-device) PDF to Markdown on the same six dimensions, with a data-backed winner per dimension and a final pick-by-use-case map.

Why convert at all: the token and structure argument

Two claims drive the "convert first" consensus, and they deserve different levels of confidence.

Claim 1 — structure survives. This one is directly verifiable. Open-source converters such as Microsoft's MarkItDown (MIT licence, first released November 2024) and IBM's Docling (MIT licence, released 2024) both document Markdown/JSON output that preserves headings, lists, and tables from digital-text PDFs. MarkItDown's project README states its purpose as producing output "for consumption by LLMs and related text analysis pipelines." You can confirm this yourself on any ten PDFs from your own corpus.

Claim 2 — token consumption drops 30–50%. Treat this as an order-of-magnitude planning heuristic, not a measurement. Here is the honest state of the evidence:

• Statistical scope and method. The range comes from practitioner benchmarks that extract the same document twice — once with a raw text extractor (for example PyMuPDF or pdfplumber) and once as clean Markdown — then tokenize both with the same tokenizer (commonly tiktoken's cl100k_base). Savings are largest when the raw extraction carries page numbers, running headers, footers, hyphenated line breaks, and column-interleaved text; savings shrink toward zero for short or quote-dense documents.
• What we could not find. As of 1 June 2025 we could not identify a peer-reviewed study or a vendor-published benchmark that establishes a single authoritative percentage. Anyone quoting "30–50%" as a fixed property of Markdown is overstating the evidence.
• What to do instead. Run the measurement on 20–50 documents from your own corpus before you size a budget. The recipe takes about an hour and is described under Dimension 4.

The practical conclusion holds either way: Markdown is the better intermediate format, and the size of the win is something you should measure rather than assume. See also token budgeting for LLM applications and chunking strategies for RAG pipelines.

At a Glance

• Same problem, different trade-off. Both cloud and local (on-device) conversion turn PDFs into structure-aware Markdown before they reach an LLM. Reported token savings versus raw PDF text extraction run in the 30–50% range for text-heavy documents — a heuristic, not a constant, and worth measuring on your own corpus.
• Privacy is the sharpest divider. Local (on-device) conversion keeps the source file on hardware you control; cloud services require uploading the document to third-party infrastructure.
• Cloud wins on throughput and maintenance; local (on-device) wins on marginal cost and data residency. Very large corpora and burst volume favor cloud; sensitive documents and per-document cost favor local (on-device).
• Output quality depends more on the converter and the source PDF than on where it runs. The two open-source converters cited above document support for heading, list, and table preservation; scanned PDFs need OCR on either side.

Comparison Dimensions

To compare fairly, both options are scored on the same six criteria:

1. Privacy and data residency — does the source document leave your device?
2. Cost and pricing model — recurring subscription, metered usage, or free/one-time?
3. Throughput, scale, and batch processing — how many documents per hour, and does it parallelize?
4. Output quality and structure fidelity — headings, lists, tables, and RAG-ready chunking.
5. Ease of setup and maintenance — installs, dependencies, updates, and engineering time.
6. Limits — file size caps, page caps, and rate limits.

Side-by-Side

Dimension 1: Privacy and Data Residency

• Cloud / hosted: The document must be uploaded. Managed document-AI services — for example, Azure AI Document Intelligence, Amazon Textract, and Google Document AI — process files on vendor infrastructure. Enterprise data-processing agreements and encryption in transit and at rest are standard, but the source file still leaves your network and becomes subject to the vendor's retention and subprocessor policies. For legal filings, medical records, or proprietary research, that upload is the decisive risk.
• Local (on-device): The file never leaves hardware you control. Open-source converters such as MarkItDown and Docling run as a CLI or library with no network call required. Some browser-based tools perform conversion client-side using WebAssembly or JavaScript, in which case the PDF is read by the page and never transmitted — but "runs in your browser" is a claim you should verify, not assume: open your browser's developer tools, switch to the Network tab, convert a file, and confirm no outbound request contains the document.
• Winner: Local (on-device) — for any document you would not email to a stranger. Cloud remains workable when the PDFs are public or non-sensitive. If you must use cloud on sensitive material, pair it with PII redaction before sending documents to an LLM.

Dimension 2: Cost and Pricing Model

• Cloud / hosted: Metered per page, sometimes plus a subscription. Published list prices for managed OCR/parsing sit at roughly $1.00–$1.50 per 1,000 pages for the entry tiers (Azure AI Document Intelligence Read model, AWS Textract DetectDocumentText, and Google Document AI OCR all price in this band as of 1 June 2025; verify current rates on each vendor's pricing page). Pricing is predictable and easy to budget per seat or per pipeline, but it scales linearly with volume and stops working if you stop paying. The smaller your corpus, the less this matters — 10,000 pages is on the order of $10–$15 in raw OCR cost.
• Local (on-device): Zero licence cost for the open-source converters named above; you pay in compute, engineering time, and the electricity or cloud VM you run it on. Marginal cost per document trends toward zero once the hardware is already owned, which is why local (on-device) wins on steady, sustained volume — but only after the setup cost is amortized.
• Winner: Local (on-device) on marginal cost per document at sustained volume; cloud if you prefer flat, predictable billing over capital or setup effort, or if your volume is too low to justify building a pipeline.

Dimension 3: Throughput, Scale, and Batch Processing

• Cloud / hosted: Elastic by design. Large jobs can be parallelized across vendor infrastructure without touching your laptop's memory or CPU, and all three major services offer asynchronous batch modes for multi-thousand-page jobs.
• Local (on-device): Bounded by device resources — RAM, CPU, and, for browser-based tools, browser memory. Docling and MarkItDown both expose batch or batch-conversion code paths, but the ceiling is your hardware. A modern laptop handles hundreds of pages comfortably; tens of thousands of pages become a scheduling problem.
• Winner: Cloud for corpora in the thousands of documents or one-off bulk migrations with a deadline. Local (on-device) is adequate for hundreds of documents on a modern laptop.

Dimension 4: Output Quality and Structure Fidelity

• Cloud / hosted: Structure-aware extraction is standard at the major vendors. Azure Document Intelligence, Textract, and Document AI all publish layout, table, and reading-order capabilities. Quality varies by PDF type — digital-text PDFs are near-perfect; scans depend on the OCR engine.
• Local (on-device): Comparable targets. Docling's documentation describes layout analysis and table-structure recovery producing Markdown or structured JSON; MarkItDown targets heading, list, and table preservation. Scanned PDFs need an OCR pass (for example Tesseract, Apache-2.0) on either side.
• Winner: Tie. Structure fidelity depends far more on the converter's parsing logic and on whether the source PDF contains digital text or is a scan than on the deployment model. Measure it rather than trust it: take 20–50 documents from your own corpus, extract each twice — once raw, once to Markdown — tokenize both with the same tokenizer, and count heading/table survival by hand. That gives you a defensible number for your pipeline instead of a vendor's. See also OCR vs. text extraction for LLM pipelines.

Dimension 5: Ease of Setup and Maintenance

• Cloud / hosted: An API key and an HTTP call. No installs, no dependency updates, no local compute to manage. The trade-off is that you inherit the vendor's quotas, error taxonomy, and version churn.
• Local (on-device): CLI and library tools such as MarkItDown and Docling install via pip and require Python version management, dependency updates, and occasional upgrades; self-hosting adds container and OS maintenance. Browser-based, client-side converters require no install at all, which makes them effectively as frictionless as cloud for one-off jobs.
• Winner: Cloud for teams with no engineering capacity; effectively tied when the local (on-device) option is a self-contained CLI install or a client-side browser tool.

Dimension 6: Limits, File Size, and Rate Caps

• Cloud / hosted: Caps are published per service and per API mode. As of 1 June 2025: AWS Textract's asynchronous API accepts PDFs up to 500 MB and 3,000 pages per document, while its synchronous API is capped at roughly 10 MB per request; Azure AI Document Intelligence supports up to 500 MB per document on the S0 tier for its Read model; Google Document AI's synchronous processing caps online files at around 20 MB. These caps are plan- and mode-dependent and are monetized — larger files and higher volumes cost more. Always confirm against each vendor's current quotas documentation.
• Local (on-device): File size is bounded by available memory, not by a licence tier. There is no daily conversion counter and no per-page charge. The practical ceiling is the point at which a single document exhausts the RAM of the machine doing the work.
• Winner: Cloud for very large single files and short bursts that exceed local memory; local (on-device) for sustained volume, because there is no metered cap.

Feature Table

When to Choose Option A: Cloud / Hosted Conversion

• Your PDFs are public, published, or otherwise non-sensitive.
• You need to process thousands of documents in a short window and have no spare local compute.
• Your team has no engineers to install, update, or maintain a local pipeline.
• You want metered or flat, predictable billing and vendor-side batch orchestration.
• You need conversion as a step inside an existing server-side pipeline, not on a user's machine.

When to Choose Option B: Local (On-Device) Conversion

• Documents are legal, medical, or proprietary research that cannot be uploaded.
• You are feeding confidential PDFs into an AI tool and do not want the source file or your API key to leave the device.
• Your volume is steady rather than bursty, and per-document cost matters more than raw peak throughput.
• You work offline or on an air-gapped machine.
• You prefer a self-contained CLI install, or a client-side browser tool whose network traffic you have verified, or a self-hosted pipeline such as Stirling PDF for full control.

FAQ

Q1. Does converting PDF to Markdown actually reduce LLM costs?

It reduces token count, and token count is what you pay for — but the size of the reduction is frequently overstated. Practitioner benchmarks that extract the same PDF twice (raw text vs. clean Markdown) and tokenize both with the same tokenizer report savings in the 30–50% range for text-heavy documents with headers, footers, and multi-column layouts; savings approach zero for short or quote-dense documents. We found no peer-reviewed or vendor-published benchmark establishing a single authoritative figure as of 1 June 2025. The secondary benefit is more reliable: headings, lists, and tables survive conversion, so retrieval chunks carry usable structure instead of a flattened text stream.

Q2. Is local (on-device) conversion fast enough for a large RAG corpus?

For hundreds of documents on a modern laptop, generally yes — CLI and library converters support batch runs, and the bottleneck is CPU time rather than a licence cap. For tens of thousands of documents or a one-off migration with a deadline, cloud parallelism is the pragmatic choice because the file-size and page limits are published and the work distributes across vendor infrastructure. This is a judgment call based on your hardware and deadline, not a vendor specification.

Q3. Can I use cloud conversion for confidential documents?

Technically yes, and every major cloud document-AI service publishes encryption and data-processing documentation. But the source file still leaves your device and lands on third-party infrastructure, which is the exact exposure local (on-device) conversion eliminates. If the document is covered by a confidentiality obligation, treat local (on-device) as the default and cloud as the exception requiring sign-off — usually paired with redaction and a retention clause negotiated into the contract.

Q4. Do I need conversion at all, or can I just paste PDF text into the prompt?

You can, but it is the least efficient path. Raw PDF text streams waste tokens and lose document structure before the model ever sees them, which degrades both cost and answer quality. Markdown is the intermediate format that addresses both problems. The one case where conversion adds little is a short, single-column, quote-dense document — exactly the case where the token-saving heuristic collapses, which is why measuring beats assuming.

Verdict

Neither option wins outright. Choose cloud when your documents are non-sensitive, your volume is high or bursty, and you want no local setup or maintenance. Choose local (on-device) when the documents are confidential, when per-document cost matters at sustained volume, or when you need offline operation — an open-source CLI converter or a client-side browser tool covers most individual and small-team needs without sending a single byte off the machine.

For mixed environments, the practical pattern is a split pipeline: route confidential, regulated, and one-off documents through local (on-device) conversion, and route public, high-volume batches through a hosted service. That keeps the privacy-critical path on hardware you control while preserving cloud elasticity for everything else.

Key Facts

• Converting PDFs to Markdown before feeding them to an LLM preserves headings, lists, and tables, and produces RAG-ready chunks. Both properties are documented by MarkItDown and Docling.
• Reported token savings versus raw PDF text extraction run in the 30–50% range for text-heavy documents. This is a practitioner heuristic, not an established constant; measure it on 20–50 documents from your own corpus using the same tokenizer on both versions.
• Local (on-device) conversion keeps the source PDF — and the user's AI API key — from leaving hardware you control, which matters for legal, medical, and proprietary research documents.
• Cloud conversion requires uploading the file to vendor infrastructure. Entry-tier list prices for the three major managed OCR services sit at roughly $1.00–$1.50 per 1,000 pages as of 1 June 2025; verify current rates on each vendor's pricing page.
• Published cloud file limits as of 1 June 2025: AWS Textract asynchronous up to 500 MB / 3,000 pages and synchronous roughly 10 MB; Azure AI Document Intelligence S0 up to 500 MB per document; Google Document AI online processing around 20 MB.
• Cloud wins on throughput and maintenance; local (on-device) wins on marginal cost per document and data residency. Structure fidelity is a tie and depends on the converter and source PDF type, not the deployment model.

Sources

1. Microsoft, MarkItDown — open-source PDF/DOCX/PPTX-to-Markdown converter for LLM pipelines. Repository and README, MIT licence, first published November 2024. https://github.com/microsoft/markitdown
2. IBM Research, Docling — open-source document conversion with layout analysis and table-structure recovery. Repository and documentation, MIT licence, 2024. https://github.com/docling-project/docling
3. Amazon Web Services, Amazon Textract quotas and pricing. Retrieved 1 June 2025. https://docs.aws.amazon.com/textract/latest/dg/limits-document.html and https://aws.amazon.com/textract/pricing/
4. Microsoft, Azure AI Document Intelligence service quotas and pricing. Retrieved 1 June 2025. https://learn.microsoft.com/azure/ai-services/document-intelligence/service-limits and https://azure.microsoft.com/pricing/details/ai-document-intelligence/
5. Google Cloud, Document AI quotas and pricing. Retrieved 1 June 2025. https://cloud.google.com/document-ai/quotas and https://cloud.google.com/document-ai/pricing
6. Tesseract OCR — open-source OCR engine, Apache-2.0 licence. https://github.com/tesseract-ocr/tesseract
7. Stirling PDF — self-hosted PDF tooling, AGPL-3.0 licence. https://github.com/Stirling-Tools/Stirling-PDF

Token-savings methodology note: the 30–50% range cited throughout this article is a synthesis of practitioner benchmarks that extract the same document twice and tokenize both versions with the same tokenizer (tiktoken, cl100k_base is the common choice). It is not a vendor claim and not a peer-reviewed finding. We state this explicitly so you can reproduce or falsify it on your own corpus.