Firecrawl /parse: The Shortest Path from Local Files to LLM-Ready Data

If your team is building a RAG system or automating document workflows, you have hit this gap: web content is easy to scrape, but contracts, reports, invoices, and user-uploaded files live on disk, messy and varied, demanding a homemade cleanup pipeline before any LLM can touch them. Firecrawl’s /parse endpoint, launched April 28, closes that gap: upload a local file directly and get back the same clean output the web pipeline produces — PDFs keep their reading order and tables, Word docs shed their XML noise, spreadsheets become tidy tabular Markdown, and you can request a summary or structured JSON extraction in the very same call.

One API Now Covers Both Web and Local Documents

/parse positions itself as the local-file sibling of /scrape: both run the same parsing engine and return the same output shapes, which means your downstream pipeline (cleanup, chunking, vector-store ingestion) is written once. The announcement states the use case plainly — many of the documents you need to process (contracts, reports, invoices, uploaded files) live on disk, not on the web. That path used to mean wiring your own OCR or document library; now it converges with web scraping into a single API.

Supported formats: PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, and HTML, with files up to 50 MB. Anything outside the list returns an UNSUPPORTED_FILE_TYPE error — no guessing. For existing /scrape users, migration cost is effectively zero: the only change is swapping a URL for an upload, while parameters and response shapes stay exactly as they were.

The Rust Engine: Not Faster OCR, Less OCR

Under the hood, /parse runs a Rust-based engine averaging under 400ms per page. The real design point is that it does not route every page through OCR — it classifies first:

• Text-based pages get native extraction. The open-source Rust library pdf-inspector reads PDF internals (fonts, text operators, image coverage) and pulls text in milliseconds, with no rendering at all.
• GPU only where it matters. Scanned and image-heavy pages are routed to a GPU fleet with lane-based isolation — a 200-page report never slows down someone else’s single-page invoice.
• Layout-aware accuracy. A neural layout model detects tables, formulas, text blocks, and headers individually, then tunes parameters per region: tables get higher token budgets, formulas are preserved in LaTeX, and reading order for multi-column documents is predicted neurally.

The tiered strategy keeps speed and cost honest: text pages stay on cheap native extraction, and the expensive GPU is reserved for scans that actually need it.

One Call, Two Outputs: Markdown Plus Typed Fields

The most practical detail is that schema extraction is embedded in the upload call itself. For a contract, pass the JSON schema along with the file:

import requests
import json

with open("contract.pdf", "rb") as f:
    response = requests.post(
        "https://api.firecrawl.dev/v2/parse",
        headers={"Authorization": "Bearer fc-YOUR_API_KEY"},
        files={"file": f},
        data={
            "options": json.dumps({
                "formats": ["markdown", "json"],
                "json": {
                    "schema": {
                        "type": "object",
                        "properties": {
                            "parties": {"type": "array", "items": {"type": "string"}},
                            "effective_date": {"type": "string"},
                            "total_value": {"type": "string"}
                        }
                    }
                }
            })
        }
    )

data = response.json()["data"]
print(data["markdown"])
print(data["json"])

The response contains markdown — full text with tables and reading order intact — and json, the typed fields your schema requested (parties, effective date, total value). One call, both outputs, no second parsing step. For RAG, the result is embedding-ready: structure preserved, tables intact, a summary available in the same response, ready to chunk and send to your vector store.

Billing, Caching, and Scan Quality: Three Limits to Know Up Front

The announcement is candid about constraints. First, every call re-parses: results are never cached, and re-uploading the same file is billed each time; the credit model matches /scrape — one call plus any LLM formats you request, such as JSON extraction. Second, a scanned PDF’s ceiling is its scan quality: clean scans parse cleanly, while low-resolution or handwritten content degrades, because those pages ultimately go through OCR. Third, fixed formats and size caps: 50 MB and the eight listed types, with no gray area.

One compliance-relevant detail: Enterprise plans with Zero Data Retention (ZDR) enabled ensure parsed output is never stored — for teams handling contracts, medical records, or internal reports, that is a prerequisite check before handing a document pipeline to a third-party service.

What Builders Should Take Away

/parse is available now to all Firecrawl API users, with two direct applications:

1. In-app file uploads: users drop PDFs or DOCX into your product; one call yields Markdown plus structured fields, and everything downstream — vector store, workflow triggers, database writes — consumes one consistent format.
2. A unified document pipeline: email attachments, downloaded reports, web pages, and user uploads all flow through Firecrawl, so you maintain one fewer homemade parser.

The onboarding advice is straightforward: run a batch of your real documents first — especially scanned files and multi-column tables — because scan quality and layout complexity are the biggest variables in output quality; a live test beats any spec sheet. And if your workload reprocesses the same files, remember that “no caching, billed per call” belongs in your cost model — consider caching parsed results on your side so repeat processing of an unchanged document stays free.

Sources

• Introducing /parse: Turn any document into LLM-ready data

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.