Camelot
Python library dedicated to pulling tables out of PDFs, with a parser chosen per document and pandas DataFrames as the output.
Jobs Extract
Since 2018
Opens the vendor's own site.
Jobs covered
Open a task to see exactly what the vendor documentation supports.
Extract
Browse all extract toolsextracting tables from text-based PDFs with the Camelot Python library, returning each table as a pandas DataFrame and exporting it to CSV, JSON, Excel, HTML, Markdown or SQLite, taking a file path, URL, raw bytes or binary file-like object as input
Where your files are processed
No server involved
A Python library that reads a file from disk and returns tables. No hosted service exists to send anything to. That is a property of the library itself: what an application built with it does with your file depends on that application, not on this.
Architectural and documented: read_pdf() takes a path, a URL, raw bytes or any binary file-like object, and the library reads the document in-process. There is no hosted service, no account and no upload endpoint described in the README, docs or package metadata.
The only outbound network call possible is one you make yourself by passing an HTTP URL as the filepath.
What it does
Camelot extracts tables from text-based PDFs and returns each one as a pandas DataFrame, with exporters for CSV, JSON, Excel, HTML, Markdown and SQLite. It offers a choice of parsers rather than one: lattice reads the ruled grid from the page, stream infers columns from whitespace, network grows a table from text alignments, hybrid merges the line and alignment signals, and an optional neural backend handles dense borderless tables and, with OCR, scans.
Each table carries accuracy, whitespace and confidence metrics so poor extractions can be filtered without reading them.
Best for
Analysts and engineers turning reports, statements and government tables into DataFrames, especially where the layout is ruled and repetitive and the table regions, columns or row grouping need to be tuned per document.
Worth knowing
No single parser wins on all documents, and the failure modes are documented per parser rather than hidden. The default lattice parser only works where cells are demarcated by lines; the stream parser needs whitespace between cells and its automatic detection can misjudge the table area when text is far apart vertically, needing edge_tol tuning; the project's own comparison page rates the heuristic parsers at their ceiling on borderless tables, where the optional ml backend roughly doubles the reported TEDS score but pulls in PyTorch.
Scanned or image-only PDFs still need the ml and ocr extras, so the README's line that the built-in parsers need a text layer remains true. The dependency story has also moved: ghostscript is no longer required for image conversion (pdfium replaced it in v1.0.0) but is still an optional backend installing a system binary, and the ocr extra pulls rapidocr-onnxruntime, which hard-requires the full opencv-python even though Camelot itself uses the headless build.
Finally, the 2.0 documentation contradicts itself on defaults: the advanced page still describes engine='raster' and line_scale 40 as the defaults, while the migration guide and changelog say engine='combined' and line_scale 15.
Details, and where each comes from
Vendor statements, our own reading of their pages, and the things nobody has established yet, each answered separately. Where we have not confirmed something it says so rather than guessing, and a row nobody has established is greyed out.
- Versions covered
- Windows · macOS · Linux · Self-hosted
- Website
- camelot-py.readthedocs.io
- Requires an account
- Not applicable
- Watermark on the free tier
- Not verified
- Maximum file size
- Not verified
- Batch processing
- Yes
- Data residency
- Self-hosted
- Open source
- Yes
- Self-hostable
- Yes
- Licence
- MIT
- Redaction
- No redaction feature
- Programmatic access
- Embeddable library · Command line
- Last availability check
- Responded in 243 ms 21 October 2026
Checked automatically by our own runner, not reported by the vendor. 100% of our last 30 checks got a response.
What the redaction verdict rests on
From the vendor's own documentation, read 22 September 2026. Not tested by us.
What that does not establish
The vendor’s own site was read on 22 September 2026 and contains no mention of redaction, sanitisation, blackout or whiteout. Absence from a vendor’s own material is not proof that a feature does not exist - it may be undocumented, or on a page the reading did not reach - but for a NEGATIVE claim it is the strongest evidence available, and it is weaker than a positive quote.
Recorded as such rather than presented as certainty.
What the vendor says
Claims are labelled rather than repeated as fact. Where we have checked something ourselves, it says so and shows when. Checked means we read the vendor's own page and it says what we recorded - not that we tested the behaviour, unless the note says we did.
-
“The `ml` backend keeps Camelot honest: the model only supplies the table **structure**, while cell **text** comes from the PDF's own text layer (or OCR for scans) - so it never invents or alters a value.”
Checked by us - the source says this Read 22 September 2026
Confirmed verbatim: the sentence appears unaltered in the README's description of the `ml` backend. It is a claim about what the model does *not* do, which makes it more checkable than most capability claims in this tier: the architecture described - model supplies structure, text comes from the PDF's own text layer or OCR - is the design that would produce the stated property, and a reader can verify it against the code.
We did not read the code for this entry. Recorded as the project's description; no control was run.
Standing: Re-read and matched byte for byte
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 958b40b32df502b1e6290c493f69e2706685f49cbc34f693c9459ae06aa812a1
How we checked
Re-verified verbatim on 2026-09-22: https://github.com/camelot-dev/camelot re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-github-com-camelot-dev-camelot-28328864.txt.
-
“Camelot's default image-conversion backend is [pdfium](https://pypi.org/project/pypdfium2/), which ships as a wheel - so a plain install needs **no system dependencies**.”
Checked by us - the source says this Read 21 September 2026
Confirmed verbatim. The README states the same thing twice - "Light install - the default pdfium backend is bundled, with no system dependencies" in the feature list, and the fuller sentence the claim quotes.
The second half of that sentence is the qualification the claim leaves out and a reader needs: "The optional ghostscript and poppler backends require additional dependencies." So "no system dependencies" is true of the default install and false the moment a user follows any older Camelot guide that switches backends. This is the same shape as several claims in the licensing tier: accurate as written, and only safe with the sentence that follows it.
Standing: Re-read and matched byte for byte
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 1ca9706a966c858b1c742a81c8191ef614b06c6500614148c38bf8907ddf28df
How we checked
Same page and same read as the claim above: https://github.com/camelot-dev/camelot rendered in headless Chrome on 2026-09-21, visible text 7923 bytes. sourceHash is the SHA-256 of the rendered text.
-
“**No**, Camelot only works with text-based PDFs and not scanned documents.”
Checked by us - the source says this Read 22 September 2026
Confirmed verbatim: the FAQ's first question is answered with the word "No" and the claim's sentence. The rest of the answer and the parenthetical quote it borrows from a neighbouring project are worth recording together, because the two tools are in this index and say nearly the same thing: Camelot quotes Tabula, "If you can click and drag to select text in your table in a PDF viewer, then your PDF is text-based".
Tabula's own README, verified in this same batch, gives the same test in almost the same words. So the boundary between these two libraries and scanned documents is stated identically by both, which makes it a property of text-layer extraction rather than a limitation of either project.
Standing: Re-read and matched byte for byte
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 4579b7599ca08aa67ec261804afacd14df06f7960b2c3ff441785f2fc0fd2c25
How we checked
Re-verified verbatim on 2026-09-22: https://camelot-py.readthedocs.io/en/latest/user/faq.html re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-camelot-py-readthedocs-io-en-latest-user-faq-html-ee53c6bf.txt.
-
“`'combined'` is **safe to try on any lattice PDF**: raster detection always runs first, so the vector lines can only _add_ to what was found, never remove it.”
Checked by us - the source says this Read 22 September 2026
Confirmed verbatim, and the sentence continues with the guarantee that makes it concrete: "On a PDF whose rules the rasteriser already detects cleanly, engine='combined' returns exactly the same tables as engine='raster'." The page documents all four engines and their trade-offs, so a reader can see where the claim's safety comes from - combined runs raster detection and unions in vector ruled lines, and because it only adds, the worst case is the raster result.
The claim is accurate and it is a description of a design property rather than a measured result. Recorded as the project's documentation; no control was run.
Standing: Re-read and matched byte for byte
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 2949b8ebc9292aa812f190b2088dd073a22396a828a42bfbabeaff152a43a811
How we checked
Re-verified verbatim on 2026-09-22: https://camelot-py.readthedocs.io/en/latest/user/advanced.html re-rendered in headless Chrome with scripts/render-page.mjs and the claim's wording found in the rendered text. Originally verified on 2026-09-21. sourceHash is the SHA-256 of the re-rendered text, held as rv-camelot-py-readthedocs-io-en-latest-user-advanced-html-b7c3c4c2.txt.
Each claim is quoted from the vendor's own pages. This section describes what we have and have not checked - it is not a judgement about anyone.
Sponsorship is distribution, not an endorsement or a promise of search rankings, AI citations, traffic, or sales. This listing is a free entry, compiled from published sources.
Related reading
- Which PDF tools keep your file on your machine - what we count as processing on your own device.
- Open source PDF tools, and what their licences require - what open source does and does not tell you.