How do you convert PDF files to JSON? (2026)

• A PDF has no fields to export: it stores positioned text runs, fonts and drawing instructions, so every converter has to rebuild words, lines, tables and labels before it can write JSON.
• Local libraries return layout, not meaning: Docling, PyMuPDF and pdf2json give you each piece of text with its page and bounding box, while pdf-parse returns one text string plus document metadata.
• Schema-guided parsing returns data you can use: Firecrawl's /parse endpoint takes a JSON schema or a prompt and returns the document in that shape, for PDF, Word, Excel, PowerPoint, EPUB, CSV and HTML files.
• Scanned PDFs need OCR: text-layer libraries return nothing for an image-only page, while Firecrawl's PDF parser extracts embedded text first and runs OCR only on the pages that need it.
• A one-off file needs no code: Firecrawl's free PDF to JSON converter takes a PDF URL and returns structured JSON with no signup.

Converting PDF files to JSON opens up all sorts of possibilities in software. Document extraction is one of the most sought after skills in the data industry. When we think of the internet, we usually picture dynamic pages, beautifully rendered HTML, single page applications (SPAs) meant to handle entire workflows end to end.

The internet is the world's largest repository of human knowledge. We don't normally think about how this knowledge is stored. In the first iteration of the internet, things weren't always served in an HTML page. Smaller pages used handwritten HTML. Larger documents got stored in other formats like PDF.

This post compares five libraries for converting PDFs to JSON: Docling, PyMuPDF, pdf2json, pdf-parse, and Firecrawl. Each is run against the same 1902 edition of Plato's Crito so the outputs are directly comparable.

JSON is the de facto language of the modern internet. Data gets stored in key-value pairs. Each object has a schema. When it's strongly enforced, this schema makes data usable from nearly anywhere. JSON doesn't care if you're using Python, JavaScript, Rust, or any other programming language for that matter. This makes JSON ideal for RAG pipelines.

Most REST APIs return JSON. Model Context Protocol (MCP) servers don't just return JSON. They're controlled using JSON as well. JSON powers the vast majority of modern web applications. The beauty of JSON is its simplicity. A JSON object is just fields of text with a minor set of rules attached to it.

Think of the following object.

Person

• Name: Jacob
• Age: 35
• Job: Writer

To a human, this is understandable. To deterministic software, the list above is just some loose, possibly unrelated data that's been grouped closely together on a page. To render this person in JSON, we'd lay it out like this.

{
  "name": "Jacob",
  "age": 35,
  "job": "writer"
}

Then, we can retrieve information by calling the fields. If we call print(object["name"]), we should see Jacob appear in the terminal. To get the person's age, we could call print(object["age"]).

PDF files don't inherit this structure. PDF data has almost no predefined structure at all. It's meant for free text. On top of that, PDF data isn't stored as text. It's stored in a binary format.

Electric bills, tax forms, historical texts, academic papers: PDF is where a huge share of the world's important information lives, and none of it is friendly to modern software. Converting PDF data into JSON without losing its integrity is what makes an electric bill readable by a machine or a century-old text queryable by an LLM.

Most traditional parsing techniques fail during a process called Optical Character Recognition (OCR). OCR has been tricky ever since we started scanning physical documents for upload in the digital world. Today, it's much better than it was thirty years ago. In fact, most commercial OCR software does a decent enough job. When you scan a document that was printed yesterday, your machine will likely parse it with no issues. Things get more difficult when dealing with older texts and texts with mixed formatting.

Your electric bill might come with an itemized table and a few paragraphs summarizing recent changes to provider policy. If you're analyzing a century old text, it might fail because it was handwritten. It also might fail because the ink is worn. Even an obscure typewriter font or a poorly aligned page can cause the parser to fail once it's been scanned.

This isn't unique to deterministic parsers either. Applied AI's open-source PDF-Bench tested 18 parsers, including commercial APIs, on more than 800 documents in November 2025. Two of its findings matter most here.

1. No single parser won on every document type, so the right pick depends on the documents you have.
2. Document complexity set the ceiling. Simple legal text scored up to 98%, while academic papers scored around 30%, because of their mix of tables, layouts, figures and free text.

The authors updated the repository in November 2026 to note that scores from its separate runs can't be merged into one ranking, so read any parser leaderboard as specific to the documents it tested.

Intelligent parsing isn't all bad. Carbonized scrolls from Mt. Vesuvius are much more difficult to extract than PDF data. However, with AI-powered software, even these are valid candidates for data extraction. Researchers have even been able to virtually unwrap a full Herculaneum scroll without ever unwrapping it.

Now, let's test out some actual libraries for converting PDF to JSON. We'll use a 1902 edition of Plato's Crito. It's available here on the Internet Archive. The file itself is only 14 pages of cleanly done OCR. This gives us a solid control variable to use while still pushing these software libraries to perform a difficult task without choking them out entirely.

Docling is built to take in numerous data formats including text, tabular, and audio data. Then it can output these into your choice of JSON, Markdown, or HTML.

We can install Docling with pip.

pip install docling

Converting our data with Docling is very straightforward. We first create an instance of DocumentConverter. We input the data using converter.convert(source). Then, we use the export_to_dict() method, which converts all of our input data to JSON. After exporting the JSON, we write it to a file.

from docling.document_converter import DocumentConverter
import json
 
source = "plato_the_crito.pdf"
 
converter = DocumentConverter()
result = converter.convert(source)
 
output_json = result.document.export_to_dict()
 
with open("docling-crito.json", "w", encoding="utf-8") as file:
    json.dump(output_json, file, indent=4)

The output below is a small snippet. We have all sorts of fields specifying the text's position on the page. We also get the original text (orig) as well as the extracted text (text). This is really useful when we need to analyze extraction, and particularly, OCR quality.

{
  "self_ref": "#/texts/136",
  "parent": {
    "$ref": "#/body"
  },
  "children": [],
  "content_layer": "body",
  "label": "text",
  "prov": [
    {
      "page_no": 14,
      "bbox": {
        "l": 89.3672550144,
        "t": 594.4359999999999,
        "r": 366.71600000000007,
        "b": 584.209568,
        "coord_origin": "BOTTOMLEFT"
      },
      "charspan": [0, 59]
    }
  ],
  "orig": "Soc. Then let me follow the intimations of the will of God.",
  "text": "Soc. Then let me follow the intimations of the will of God."
}

PyMuPDF is a Python binding for MuPDF. It's the engine that a lot of other LLM-oriented parsers (including pymupdf4llm) are built on. Install it with pip.

pip install pymupdf

We can pull structured, positional JSON straight out of PyMuPDF using page.get_text("json"). It returns a JSON string per page containing every text block, line, and span along with font, size, color, and bounding box. We iterate pages, parse each string, and write the whole list to a file.

import pymupdf
import json
 
doc = pymupdf.open("plato_the_crito.pdf")
 
pages = [json.loads(page.get_text("json")) for page in doc]
 
with open("pymupdf-crito.json", "w", encoding="utf-8") as file:
    json.dump(pages, file, indent=4)

Each span comes back with layout and typography metadata. The last line of the Crito, extracted from page 14, looks like this.

"spans": [
    {
        "size": 12.0,
        "flags": 4,
        "bidi": 0,
        "char_flags": 16,
        "font": "Baskerville Old Face",
        "color": 0,
        "alpha": 255,
        "ascender": 0.75,
        "descender": -0.17900000512599945,
        "text": "Soc. Then let me follow the intimations of the will of God. ",
        "origin": [
            90.02400207519531,
            205.82000732421875
        ],
        "bbox": [
            90.02400207519531,
            196.13217163085938,
            369.78997802734375,
            208.13217163085938
        ]
    }
]

The two most common JavaScript options for PDF to JSON extraction are pdf2json and pdf-parse. We'll run the same Crito file through both.

pdf2json is built specifically for this task. That's literally its name. You can install it using npm.

npm i pdf2json

Our code here is relatively straightforward as well. We create an instance of PDFParser. Then, we use the on() method to handle errors. We configure it to write the data to a JSON file when no error occurs. Once our parser is configured, we run the Crito through it using loadPDF().

import fs from "fs";
import PDFParser from "pdf2json";
 
const pdfParser = new PDFParser();
 
pdfParser.on("pdfParser_dataError", (errData) => console.error(errData.parserError));
 
pdfParser.on("pdfParser_dataReady", (pdfData) => {
  fs.writeFile("pdf2json-crito.json", JSON.stringify(pdfData, null, 4), () => console.log("Done."));
});
 
pdfParser.loadPDF("./plato_the_crito.pdf");

Like our other examples, each bit of extracted text comes to us nested inside a massive JSON object built primarily from document metadata.

{
    "x": 6.839,
    "y": 12.114,
    "w": 256.512,
    "clr": 0,
    "sw": 0.32553125,
    "A": "left",
    "R": [
        {
            "T": "Then let me follow the intimations of the will of God. ",
            "S": -1,
            "TS": [
                0,
                15,
                0,
                0
            ]
        }
    ]
},

Now, we'll take a look at pdf-parse. This tool is not made specifically for JSON. It's a general purpose PDF parsing library.

Install it using npm.

npm i pdf-parse

First, we create a PDFParse() object. Then we need to await the text and the metadata. After extraction, we manually remove the parser from memory using destroy(). I was very surprised to see a modern JavaScript library that requires manual memory management. After destroying the parser object, we write the text and metadata of the Crito to a JSON file.

import { PDFParse } from "pdf-parse";
import fs from "fs";
 
const parser = new PDFParse({ url: "./plato_the_crito.pdf" });
 
const text = await parser.getText();
const info = await parser.getInfo({ parsePageInfo: true });
 
await parser.destroy();
 
const output = {
  metadata: info,
  text: text.text,
};
 
fs.writeFileSync("pdf-parse-crito.json", JSON.stringify(output, null, 4));

This time, our output is different. pdf-parse takes a much more brute force approach. We don't get each line extracted as a neat object. We get the entire Crito in one line of text.

The metadata, though, is rich. pdf-parse even identified the origin software as Microsoft Office Word 2007. If you need to inspect document provenance, pdf-parse is the strongest of the libraries we tested. The extracted text is the ugliest.

For brevity, we shortened the extracted text below to show just the beginning and end of the document.

{
  "metadata": {
    "total": 14,
    "info": {
      "PDFFormatVersion": "1.5",
      "Language": "en-US",
      "EncryptFilterName": null,
      "IsLinearized": false,
      "IsAcroFormPresent": false,
      "IsXFAPresent": false,
      "IsCollectionPresent": false,
      "IsSignaturesPresent": false,
      "Author": "Plato",
      "CreationDate": "D:20140704085745-04'00'",
      "Creator": "Microsoft® Office Word 2007",
      "Keywords": "Socrates; Trial of Socrates; Justice; Death penalty",
      "ModDate": "D:20140704094222-04'00'",
      "Producer": "Microsoft® Office Word 2007",
      "Subject": "Socrates's insistence on submitting to the death penalty",
      "Title": "Crito"
    },
    "metadata": {},
    "fingerprints": ["0a01264c606e3f49a444ef99695f135b", "092165677d7c90498a026d210980024f"],
    "permission": null,
    "outline": null,
    "pages": [
      {
        "pageNumber": 1,
        "links": [
          {
            "url": "http://www.rosingsdigitalpublications.com/",
            "text": ""
          }
        ],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 2,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 3,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 4,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 5,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 6,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 7,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 8,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 9,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 10,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 11,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 12,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 13,
        "links": [],
        "width": 612,
        "height": 792
      },
      {
        "pageNumber": 14,
        "links": [],
        "width": 612,
        "height": 792
      }
    ]
  },
  "text": "CRITO\nTranslated into English\nWITH ANALYSIS AND INTRODUCTION\nBY\nB. Jowett, M.A.\nMASTER OF BALLIOL COLLEGE, REGIUS PROFESSOR OF GREEK IN THE\nUNIVERSITY OF OXFORD...\nSoc. Then let me follow the intimations of the will of God.\nCRITO\n\n-- 14 of 14 --\n\n"
}

Traditional PDF parsers extract the raw data, but the output isn't usable as is. To do anything with the extracted dialogue in software, we need a second parsing pass. Most of what comes back is leftover artifacts and document metadata.

This leaves us with two main problems.

1. Document metadata: This sits inside the file, eating up space, and does nothing for the task. If we feed it to an LLM, it's just going to eat extra tokens.
2. Schema: In this dialogue, there are two main characters: Crito and Socrates. Even when the extractor maintains the character tagged to the line, it's one solid string: "Soc. Then let me follow the intimations of the will of God."

Using our dialogue should be easy. We really just need to loop through a list of dialogue objects. Traditional parsers don't hand back data in that shape.

for dialogue_object in dialogue:
    character = dialogue_object["character"]
    line = dialogue_object["line"]
    print(f"{character}: '{line}'")

For a loop like this to work, we need intelligent parsing.

Firecrawl's parse endpoint converts an uploaded PDF to structured JSON in one call. You send the file with a JSON schema or a natural-language prompt, and Firecrawl returns the data in that shape instead of raw text runs. The same endpoint handles Word, Excel, PowerPoint, EPUB, CSV and HTML files.

Every PDF sent to Firecrawl's /parse endpoint runs through Fire-PDF, Firecrawl's Rust-based parsing engine. Rather than extracting text for document analysis, we can use natural language and a schema to convert PDF to structured data in a single call. The code below uses the Firecrawl Python SDK to extract the dialogue from the Crito.

pip install firecrawl-py

We pass the document into Firecrawl's parse() method with three key inputs:

• formats: add a json format object to have an LLM read the parsed document and fill your schema, so your code and your AI agents get fields instead of raw text.
• prompt: a natural-language instruction telling the model what to pull out.
• schema: the shape the data should come back in.

Once parsing finishes, we save the result to a JSON file.

from firecrawl import Firecrawl
from firecrawl.v2.types import ScrapeOptions
import json
 
firecrawl = Firecrawl(api_key="<your-firecrawl-api-key>")
 
doc = firecrawl.parse(
    "./plato_the_crito.pdf",
    options=ScrapeOptions(formats=["markdown", {
    "type": "json",
    "prompt": (
        "Extract the complete dialogue from this text as a sequence of speaker turns, "
        "from the very first line to the very last line of the document. "
        "The final line of the dialogue is Socrates saying he will follow the will of God. "
        "Continue extracting every exchange in order until you reach that final line. "
        "Do not summarize, condense, or skip any exchanges in the middle."
    ),
    "schema": {
        "type": "object",
        "properties": {
            "dialogue": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "character": {"type": "string"},
                        "line": {"type": "string"}
                    },
                    "required": ["character", "line"]
                }
            }
        },
        "required": ["dialogue"]
    }
}])
)
 
output_json = doc.json
 
with open("firecrawl-crito.json", "w", encoding="utf-8") as file:
    json.dump(output_json, file, indent=4)

The difference is immediate. We don't need an additional parser to use this data. We have individual dialogue objects. Each one is tied to a character from the document. This is ready for use by nearly any software. If you really wanted to, you could pair this with audio or video software and create your own mp3 or mp4 of the Crito.

doc.json mirrors the shape you defined in the schema, so the dialogue lives at doc.json["dialogue"]. Here are the last two turns.

[
    ...
    {
        "character": "Crito",
        "line": "I have nothing to say, Socrates."
    },
    {
        "character": "Socrates",
        "line": "Then let me follow the intimations of the will of God."
    }
]

This feature works for all sorts of offline documents. For more information, take a look at the full documentation on document parsing.

Firecrawl's parser can also return the positional data that Docling and PyMuPDF give you, plus per-page Markdown, at no extra cost. These options sit on the PDF parser, so you can combine them with the JSON format in the same request.

• Layout blocks: set blocks: true and each page comes back with typed blocks (title, section header, text, table, formula, figure, caption, page header and footer), each with a normalized bounding box, its reading order and a markdownSpan that points back into the Markdown.
• Per-page Markdown: set pages: true to get a pages array, which tells you which page each piece of content came from.
• Documents at a URL: if the PDF already lives at a public URL, Firecrawl's /scrape endpoint detects the file type and parses it the same way, with the same options and output.

PDF parsing costs 1 Firecrawl credit per page, the blocks and pages options add nothing, and each file can be up to 50 MB. The JSON format runs an LLM and adds extraction credits on top: our 14-page Crito run above used 18 credits in total.

The same parse call works from the Node SDK, the REST API and the Firecrawl CLI, so Firecrawl isn't limited to Python. Inside an AI agent, the Firecrawl MCP server exposes firecrawl_parse for local files, and the Firecrawl connectors for ChatGPT and Claude let you ask for a PDF as JSON in plain language.

A scanned PDF stores pictures of pages rather than text, so it needs OCR (optical character recognition) before any JSON step. Firecrawl's PDF parser handles this by default, extracting embedded text where a page has it and running OCR only on the pages that need it.

The text-layer libraries in this post can't read a scan. We rendered the last page of the Crito to an image and saved it as a separate PDF, and both PyMuPDF's get_text() and pdf-parse returned zero characters. Docling turns OCR on by default in its PDF pipeline, and it read the last line of the Crito back from the same scanned page.

Under the hood, Fire-PDF classifies every page with pdf-inspector, its open-source Rust library, in milliseconds. Text-based pages go straight to native extraction. Scanned regions go through a neural layout model and a vision-language model (GLM-OCR), so reading order, tables and formulas survive. If a page is misread, set the parser's mode to "ocr" to force OCR on every page, or "fast" to use embedded text only.

For documents where a single OCR pass isn't enough, agentic OCR puts an AI agent around the extraction to review and re-run it until the output is clean.

PDF tables are the hardest part of PDF to JSON conversion, because a PDF draws a table as lines and positioned text with no rows or cells. Firecrawl's PDF parser detects tables with a layout model and returns them as Markdown tables, which a JSON schema can then map to an array of rows.

With blocks: true, each table also comes back as a table block with its page number and bounding box, which helps when you need to cite where a value came from. For local Python work, pdfplumber's extract_table() reads bordered tables page by page, and Camelot and tabula-py are dedicated table extractors. All three need a text layer, so scanned tables need OCR first. Our roundup of the best PDF parsers for Python and RAG compares more options.

Send a JSON schema with every request and validate the result before you store it. Firecrawl's JSON format takes the schema in the request, and doc.json comes back in that shape, so you can check it against the same schema, for example through a Pydantic model.

Developers running their own models in a r/LocalLLaMA thread on reliable PDF to JSON suggest the same habits. They constrain generation to the schema with tools like Instructor or Outlines, repair near-miss output with a package such as json-repair, and set a field that fails validation to null (declared nullable in the schema) and flag it for review instead of dropping the whole record. For a wider look at schema-first tools, see our guide to JSON schema extraction.

Firecrawl's PDF parser is one of the fastest PDF parsers in the world. Fire-PDF, the Rust engine behind every PDF sent to the Firecrawl API, averages under 400 milliseconds per page and runs 3.5 to 5.7 times faster than Firecrawl's previous parser.

Its page classifier, pdf-inspector, is open source and a developer favorite, with nearly 20,000 stars on GitHub. On the opendataloader-bench corpus of 200 PDFs, pdf-inspector processed the full set in 0.47 seconds, against 17.1 seconds for PyMuPDF4LLM. It also posted the top overall score (0.875) and table score (0.814) among local engines without model-based parsing, in results dated July 31, 2026. You can read more about Firecrawl's open-source Rust document parsers.

The @firecrawl team really cooked with this one! pdf-inspector parsed my new book (155 pages) in 302ms! 100% open source

— Ran Aroussi (@aroussi), CTO-as-a-Service at Automaze

Yes, when the PDF is a published research paper. Firecrawl Alexandria's Research index holds about 43 million paper abstracts from PubMed, bioRxiv, medRxiv and arXiv, and returns each paper as a record with its title, authors, abstract, dates and source IDs.

Using the index skips the PDF step for literature work, where academic papers are the hardest documents to parse. The index can also read passages inside a paper and find related papers. Research index calls are free, within rate limits set by your plan, and you can reach them from the REST API, the Firecrawl CLI or the MCP server. The MCP tools need a signed-in or API-key connection; keyless MCP sessions don't include them. Browse Firecrawl Alexandria's research tools to see what's available.

Yes, Firecrawl's free PDF to JSON converter turns a PDF URL into structured JSON in seconds, with no signup and no code. It suits a one-off file; for batches or a pipeline, call the parse endpoint from code as shown above.

Try the free PDF to JSON converter on any public PDF, such as an invoice, an annual report or a research paper.

Every library in this article lives up to its promises. Most of these libraries give us enough metadata to rebuild an entire document from scratch. If you need to track text placement, fonts, or even the origin of the document, the local Python and JavaScript libraries we tested are nearly perfect.

If you need usable data right out of the box, Firecrawl's document parser gives you that. With intelligent parsing and custom schema, we can eliminate full portions of the traditional ETL pipeline. PDF extraction gets branded as a niche skill in this industry. With modern tooling, it's not some obscure discipline known only by sages and monks. PDF extraction, especially PDF to JSON conversion, is something the everyday developer can handle with minimal code.

If the goal is a readable overview rather than structured JSON, our roundup of the best AI PDF summarizer tools compares the tools worth reaching for and calls out which ones ship a real API, MCP, or CLI for agent workflows.