Input formats

PDF, image, DOCX, PPTX, XLSX — what the worker accepts, how format detection works, and per-format quirks.

The worker accepts five input formats through the same three sources (file_url, file_b64, volume_path). Format is auto-detected from the input bytes — there's no format field to set, and the field name file_* is intentionally format-agnostic. Send whichever source you have; the worker detects the format.

Supported formats

Format	Magic bytes	Path through MinerU
PDF	`%PDF`	Passes straight to `aio_do_parse`
Image (PNG / JPEG / GIF / BMP / TIFF / WebP)	`\x89PNG`, `\xff\xd8\xff`, `GIF8`, `BM`, `II\x00`, `MM\x00`, `RIFF`	Converted to single-page PDF via `images_bytes_to_pdf_bytes`, then parsed
DOCX (Word)	`PK\x03\x04` (ZIP/OOXML)	Parsed via MinerU's `office_docx_analyze` (python-docx)
PPTX (PowerPoint)	`PK\x03\x04`	Parsed via `office_pptx_analyze` (python-pptx)
XLSX (Excel)	`PK\x03\x04`	Parsed via `office_xlsx_analyze` (openpyxl)

DOCX / PPTX / XLSX share the same ZIP magic — MinerU's guess_suffix_by_bytes inspects the archive's [Content_Types].xml to discriminate them downstream.

What gets returned

The output shape is the same regardless of input format: Markdown + content_list + middle.json + extracted images. The exact contents differ, but the schema doesn't. A DOCX with a chart and a PDF with the same chart produce comparably structured output.

When format matters for the backend choice

The five MinerU backends (see Picking a backend) share the same input contract:

Workload	Start with	Language behavior
Digital PDF with complex layout	`vlm-auto-engine` (default)	`lang` is ignored. The model card lists English and Chinese; test other scripts on your own corpus.
Scan or image that needs explicit OCR control	`pipeline`	Set one of the supported script-family `lang` values below.
Mixed native-text and scanned pages	`hybrid-auto-engine`	MinerU combines native extraction, VLM, and pipeline OCR.
External OpenAI-compatible inference server	`vlm-http-client` or `hybrid-http-client`	Requires `server_url`; language behavior follows the corresponding VLM or hybrid path.

Office formats (DOCX/PPTX/XLSX) are parsed by MinerU's dedicated analysers regardless of which backend you set — the choice only affects which engine handles the embedded graphics / equations / scanned regions inside the document.

The `lang` parameter (pipeline backend only)

For explicit OCR language selection, set backend: "pipeline" and use one of MinerU 3.4's model-family codes, not an ISO language code:

Script family	Use for
`ch`	Chinese, English, Japanese, Traditional Chinese, and Latin-script content
`ch_server`	Server variant of the Chinese-family OCR model
`arabic`	Arabic-script content
`cyrillic`	Bulgarian, Macedonian, Mongolian, Serbian (non-Slavic Cyrillic)
`devanagari`	Hindi, Marathi, Nepali
`east_slavic`	Belarusian, Russian, Ukrainian
`el`	Greek
`ka`, `ta`, `te`	Kannada, Tamil, Telugu
`korean`	Korean (hangul)
`th`	Thai

MinerU 3.4 removed en, japan, chinese_cht, and latin as distinct model choices and routes those compatibility aliases through ch. The worker still defaults to en, which MinerU normalizes to ch. VLM backends ignore lang; test multilingual VLM output against your own documents and switch to pipeline when you need explicit OCR model selection.

Examples

PDF (English)

{
  "input": {
    "file_url": "https://example.com/report.pdf"
  }
}

The default vlm-auto-engine handles the PDF. Its lang value is ignored.

Cyrillic scan (Russian)

{
  "input": {
    "file_url": "https://example.com/russian-scan.pdf",
    "backend": "pipeline",
    "lang": "east_slavic"
  }
}

Both backends produced usable Russian output in our test: the Pro VLM handled Cyrillic, while pipeline used its explicit script-family OCR model. Treat that as a limited test, not a general script-coverage claim. For scans without an embedded text layer or when you need explicit OCR selection, start with pipeline.

Scanned image (PNG)

{
  "input": {
    "file_url": "https://example.com/page-scan.png",
    "backend": "pipeline",
    "lang": "ch"
  }
}

Image is converted to a single-page PDF internally, then routed through pipeline OCR.

DOCX with native text + embedded equations

{
  "input": {
    "file_url": "https://example.com/spec.docx",
    "formula_enable": true
  }
}

Office parser extracts native text and structure; embedded equation/image regions are sent to the chosen backend for parsing.

XLSX (spreadsheet)

{
  "input": {
    "file_url": "https://example.com/data.xlsx"
  }
}

Returns Markdown tables (one per sheet) in content_list.

Size limits

Source	Max input size
`file_b64` (inline)	Whole JSON request: 20 MB on `/runsync`, 10 MB on `/run`. Because base64 expands the file, keep raw input below roughly 15 MB or 7.5 MB respectively.
`file_url`	200 MB (worker download cap); fetched with a 120 s timeout
`volume_path`	No hard cap; only limited by the network volume's free space

The worker also rejects decoded file_b64 data over 20 MB, but the gateway's whole-request limit normally triggers first. For files up to 200 MB, use a short-lived signed object URL via file_url. For larger books or archives, pre-stage on a network volume and use volume_path — see Network volumes.

Page selection (PDF only)

The start_page / end_page fields apply to PDFs (including images converted to single-page PDFs). For DOCX/PPTX/XLSX, page-range semantics are interpreted by MinerU's Office parsers — they generally process the whole document and start_page / end_page are best-effort.

Format detection edge cases

If _detect_format returns "unknown" (the bytes don't match any known magic), the worker raises:

ValueError: input bytes do not match any supported format (PDF, PNG/JPEG/GIF/BMP/TIFF/WebP image, or DOCX/PPTX/XLSX). Check that file_b64 was base64-encoded correctly and that file_url returned the file body (not an error page).

Most common cause is file_url returning an HTML error page (e.g. a 403 from an S3 bucket with expired credentials). The first 16 bytes of the response will start with <!DOCT or <html — neither of which is in our magic table.

Input formats

On this page