pdfplumber
Python library that exposes every character, line and rectangle in a PDF, with text and table extraction built on top of that.
Where your files are processed
No server involved
A pure-Python library that parses bytes already in memory. There is no vendor service and no network component at all. 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: pdfplumber.open() takes a filesystem path, raw bytes or a file-like object, and the project describes no hosted component anywhere. Nothing in the library posts a document anywhere; there is no account, no endpoint and no telemetry described in the README. Files are read on the local filesystem and results are returned in-process.
What it does
pdfplumber is a Python library built on pdfminer.six that gives per-object access to a PDF page: each character, line, rectangle, curve, image and annotation, with its coordinates. On top of those primitives it offers text extraction, a configurable table finder whose rows and columns can be resolved from drawn lines or from word alignment, and visual debugging that draws the detected grid back over the page. It is read-only by design: it extracts and measures, it does not write, generate or modify a PDF.
Best for: Python developers and data journalists who need the layout around a table as well as the table itself: column positions, font sizes, the heading above the grid. It is a permissive MIT licence with no compiled code of its own, though installing it brings pypdfium2 and Pillow, so how it installs depends on whether wheels exist for your platform and Python version.
Worth knowing: It is a read-only library, and the project lists what it does not do: PDF generation, PDF modification, OCR, and strong support for extracting tables from OCR’ed documents. The table finder reconstructs cells from drawn lines it can see or word alignments it can infer, which works on digital pages with a text layer and does nothing for an image-only scan, because there is no text or geometry to work from. A scan needs a separate OCR step first, and even then the project does not promise strong results from that text. Borderless digital tables and scanned pages are different problems and need saying apart. Page objects cache their layout and object information, and the documentation says that on large PDFs those cached properties can require a lot of memory.
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
- github.com
- 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 388 ms 16 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.
-
“It's also helpful to know what features `pdfplumber` does __not__ provide: PDF *generation*; PDF *modification*; Optical character recognition (OCR); Strong support for extracting tables from OCR'ed documents”
Checked by us — the source says this Read 22 September 2026
Confirmed: the claim is the sentence introducing a list of four things pdfplumber does not provide, and all four items match the list exactly — PDF generation, PDF modification, Optical character recognition (OCR), and strong support for extracting tables from OCR'ed documents. The library's own reference to "strong support" rather than none is itself a careful distinction and the claim keeps it. Documenting what a tool cannot do is rare enough to be worth noting: of the libraries in this tier, this and Tesseract.js's "does not support PDF files" are the two that state their limits up front. Recorded as the project's documentation; no control was run.
Standing: Re-read: the text is unchanged, but the page publishes values that move
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 961a43459890c2ee1f1eab1dc08aa21af8f57643903700d1b379504f3465bcd8
How we checked: Re-verified verbatim on 2026-09-22: https://github.com/jsvine/pdfplumber 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-jsvine-pdfplumber-0c32ac88.txt.
-
“`pymupdf` is substantially faster than `pdfminer.six` (and thus also `pdfplumber`) and can generate and modify PDFs”
Checked by us — the source says this Read 22 September 2026
Confirmed verbatim, and this sentence sits in the library's comparison of alternatives, where the full text runs on past the claim's end: pymupdf "can generate and modify PDFs, but the library requires installation of non-Python software (MuPDF)". So the sentence the claim quotes is a favourable comparison, and the sentence immediately after it is an unfavourable one the claim truncates — for a Python-only project, needing to install MuPDF is the practical drawback. Reading the two together is the honest position: pdfplumber's own documentation says pymupdf is faster and more capable, and also harder to install. That is an unusual thing for a project to publish about a competitor, and it makes the source more useful than the claim.
Standing: Re-read: the text is unchanged, but the page publishes values that move
Check it yourself: the source, the SHA-256, and how we checked
- From
- the text a browser renders
- SHA-256
- 961a43459890c2ee1f1eab1dc08aa21af8f57643903700d1b379504f3465bcd8
How we checked: Re-verified verbatim on 2026-09-22: https://github.com/jsvine/pdfplumber 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-jsvine-pdfplumber-0c32ac88.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.