Start with a public PDF URL

pdf-to-markdown converts digital or scanned PDFs into content your agent can read and process. It accepts documents up to 30 pages and costs 0.0025 USDC per call, paid through x402 on Base mainnet.

Choose the format first. An agent preparing a summary needs readable text, while a document review tool needs to connect extracted passages to their positions on a page.

The required input is pdf_url. Send a JSON body in a POST request to the endpoint: 

{
  "pdf_url": "https://example.com/report.pdf",
  "output_format": "markdown"
}

Replace the example address with a public HTTP or HTTPS URL that returns the PDF directly. A link to a viewer or a page behind a login doesn't meet that requirement. This request takes a URL, so keep file-upload bytes out of the body.

output_format is optional. Omit it and you'll receive Markdown.

Use Markdown for text an LLM will read

Markdown is the default for workflows that pass extracted content into an LLM. It represents headings and lists in text, with support for tables and LaTeX equations. The extraction also handles documents with multiple columns.

Suppose your next step is to answer questions about a report. Heading markers give your chunking step a useful boundary, and table syntax keeps values connected to their column labels.

Here's an illustrative response with invented document content: 

{
  "markdown": "## Delivery schedule\n\n| Item | Due date |\n| --- | --- |\n| Draft | October 2 |\n",
  "output_format": "markdown",
  "page_count": 1,
  "source_url": "https://example.com/report.pdf"
}

Your application reads the markdown string. Keep source_url alongside any stored chunks so an answer can point readers back to the original document.

And check the extracted content before using it as evidence. A misplaced table value changes an answer even when the response parses correctly.

Request HTML for a document display

Set output_format to "html" when your next step needs markup that preserves more layout structure: 

{
  "pdf_url": "https://example.com/report.pdf",
  "output_format": "html"
}

The response contains an html string inside the JSON response object. Your caller still parses the response as JSON, then reads that field for the extracted markup.

This is useful for a review screen where someone reads the document beside the original PDF. A human can inspect the extracted table before approving the values for a later task.

But the format choice also changes your application code. A caller that always reads response.markdown won't find the requested content after switching to HTML. Dispatch on output_format and read the matching field.

Choose JSON for page-aware processing

Need to locate an extracted passage on its source page? Request structured JSON: 

{
  "pdf_url": "https://example.com/report.pdf",
  "output_format": "json"
}

This format returns per-page blocks with type information and bounding boxes. It's the choice for workflows that need document positions, such as connecting an extracted block to a region in a PDF review interface.

Read the document structure from the response's json field. The outer object also reports page_count, and source_url echoes the input address. output_format records which representation you requested.

The endpoint's published schema leaves the nested json object open. Inspect a returned document before writing code against particular block paths or coordinate assumptions.

So make format selection part of the agent's routing decision before it pays for extraction. Record the requested format with the stored result. If a later step needs page positions, that record tells your workflow whether its saved extraction has the structure it needs.