Summary: Firecrawl released /parse on April 28 to send local documents through the same clean-output pipeline as /scrape, supporting eight formats up to 50 MB and returning markdown plus schema-driven JSON in one call. Its Rust engine averages under 400ms per page and routes only scanned or image-heavy pages to GPU OCR. Parsing is uncached and billed per call, while Enterprise plans can enable Zero Data Retention.
Every team wiring up RAG or document automation runs into the same wall: scraping web pages is the easy part, while contracts, reports, invoices, and user-uploaded files sit on disk, messy and varied, with a hand-rolled cleanup pipeline standing between them and any LLM. Firecrawl shipped the /parse endpoint on April 28 to bring that wall down: upload a local file and receive the same clean output the web pipeline delivers — PDFs keep their reading order and tables, Word documents lose their XML noise, spreadsheets come back as tidy tabular Markdown, and a summary or structured JSON extraction can ride along in the same call.
Web Pages and Local Files, One Shared API
By design, /parse is /scrape pointed at local files: the two share one parsing engine and return matching output shapes, so the downstream work of cleanup, chunking, and vector-store ingestion only ever gets written once. The announcement frames the use case without decoration — the documents waiting to be processed (contracts, reports, invoices, uploaded files) sit on disk rather than on the web, and that route used to mean bolting on your own OCR or document library; it now meets web scraping inside a single API.
Eight formats are accepted — PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, and HTML — and a single file may weigh at most 50 MB. Anything off that list is refused outright with an UNSUPPORTED_FILE_TYPE error rather than guessed at. For anyone already on /scrape, there is essentially nothing to migrate: the file source changes from a URL to an upload, while every parameter and response shape carries over untouched.
Inside the Rust Engine: Skip OCR Wherever You Can
The engine underneath is written in Rust and averages under 400ms per page. Its defining choice is to classify pages before processing them, rather than pushing every page through OCR:
- Native extraction covers text-based pages. The open-source Rust library
pdf-inspectorreads straight into a PDF’s internals — fonts, text operators, image coverage — and lifts the text out in milliseconds, with nothing rendered along the way. - GPU time goes only where it earns its keep. Scanned pages and image-heavy pages are the ones routed to the GPU fleet, and lane-based isolation keeps a 200-page report from ever slowing someone else’s single-page invoice.
- Accuracy tuned to the layout. A neural layout model picks out tables, formulas, text blocks, and headers separately, then adjusts per region: tables receive larger token budgets, formulas survive as LaTeX, and the reading order of multi-column documents is predicted by the model.
The tiered split keeps the speed-versus-cost trade honest: text pages stay on inexpensive native extraction, and the costly GPU is spent only on scans that genuinely need it.
Upload Once, Get Markdown and Typed Fields Back Together
The detail with the most everyday value is that schema extraction lives inside the upload call itself. For a contract, send 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"])Two things come back: markdown, the full text with tables and reading order preserved, and json, the typed fields the schema asked for — parties, effective date, total value. Both outputs arrive in a single call, so a second parsing pass never gets written. In a RAG setting the result is already embedding-ready: structure intact, tables whole, a summary included when requested, ready to chunk and push into your vector store.
Three Constraints to Weigh Before Adopting: Billing, Caching, Scan Quality
The announcement puts its own constraints on the table. First, each call parses from scratch: nothing is cached, so uploading the same file again is charged again; credits work just as they do on /scrape — one call, plus whatever LLM formats you ask for, JSON extraction among them. Second, a scanned PDF’s ceiling is the scan itself: clean scans come back clean, while low-resolution or handwritten material degrades, since those pages still end up inside OCR. Third, the boundaries are fixed: 50 MB and the eight listed types, with nothing in between.
One compliance detail deserves a flag: Enterprise plans can switch on Zero Data Retention (ZDR), which keeps parsed output from ever being stored. For teams handling contracts, medical records, or internal reports, that check needs to happen before a document pipeline is handed to a third-party service.
Where Builders Can Put It to Work
/parse is open today to every Firecrawl API user. Two uses stand out as immediately practical:
- File uploads inside your product: a user hands your app a PDF or DOCX, one call returns Markdown plus structured fields, and whatever happens next — vector store, workflow trigger, database write — reads that one consistent format.
- A single document pipeline: email attachments, downloaded reports, web pages, and user uploads all travel through Firecrawl, leaving one fewer homemade parser to maintain.
Getting started takes little ceremony: grab a real batch of the documents you actually receive — scanned pages and multi-column tables above all — and run it through once to judge output quality. Scan quality and layout complexity swing the results more than anything else, so a live run tells you more than any spec sheet. If your workflow keeps reprocessing the same files, fold “no caching, billed per call” into your cost model — caching parsed results on your own layer keeps repeat processing of an unchanged document free.