DEV Community: Ai tools overview

How to Summarize PDFs Locally with Open-Source LLMs (No API, No Data Leaving Your Machine)

Ai tools overview — Fri, 17 Jul 2026 08:00:24 +0000

Most "summarize a PDF with AI" tutorials send your document to a cloud API. That's fine — until the document is a contract, a patient record, or anything your compliance team would rather not ship to a third party. The alternative in 2026 is genuinely good: run an open-source model locally, so the bytes never leave your machine and you pay $0 per token.

Here's how to build a local PDF summarizer with Ollama and Llama 3, plus an honest look at where local wins and where it doesn't.

Why local (and why not)

Local wins when:

Privacy/compliance — the file can't leave your infrastructure.
Volume — you summarize thousands of docs and don't want a per-token bill.
Offline / air-gapped environments.

Local costs you:

Hardware — you want a decent GPU (or Apple Silicon) for reasonable speed; CPU-only works but is slow.
Quality ceiling — a 7B–8B local model is weaker at long, nuanced documents than a frontier cloud model.
Ops — you own the setup, the model updates, and the tuning.

If none of those first three apply to you, a cloud API or a no-code tool is probably less hassle (more on that at the end).

Step 1: Install Ollama and pull a model

Ollama makes running local models a one-liner. After installing it:

ollama pull llama3.1:8b
# smaller/faster: ollama pull llama3.2:3b
# stronger, needs more VRAM: ollama pull llama3.1:70b

Model choice is the main quality/speed dial. 3B is fast and fine for short docs; 8B is the sweet spot for most machines; 70B approaches cloud quality if you have the VRAM.

Step 2: Extract the text

Same as any pipeline — native PDFs give text directly; scanned PDFs need OCR first.

from pypdf import PdfReader

def extract_text(path: str) -> str:
    reader = PdfReader(path)
    return "\n".join((page.extract_text() or "") for page in reader.pages)

If this comes back nearly empty, the PDF is scanned — run it through Tesseract (pytesseract) before continuing.

Step 3: Chunk, then summarize with the local model

Local models have context limits too, so long documents still need the map-reduce pattern: summarize each chunk, then summarize the summaries. The only difference from a cloud pipeline is the client — we call Ollama instead of a remote API.

# pip install ollama pypdf
import ollama

MODEL = "llama3.1:8b"

def chunk(text: str, size: int = 8000, overlap: int = 400):
    step = size - overlap
    return [text[i:i + size] for i in range(0, len(text), step)]

def summarize(text: str) -> str:
    resp = ollama.chat(
        model=MODEL,
        messages=[
            {"role": "system", "content": "Summarize the text into concise bullet points. Keep names, numbers, and conclusions. Do not invent anything."},
            {"role": "user", "content": text},
        ],
        options={"temperature": 0.2},  # lower = more faithful, less creative
    )
    return resp["message"]["content"]

def summarize_pdf(path: str) -> str:
    text = extract_text(path)
    if len(text.strip()) < 50:
        raise ValueError("Almost no text extracted — this PDF is probably scanned. OCR it first.")
    partials = [summarize(c) for c in chunk(text)]
    combined = "\n\n".join(partials)
    return summarize("Combine these section summaries into one structured summary:\n\n" + combined)

if __name__ == "__main__":
    print(summarize_pdf("report.pdf"))

Note the smaller chunk size (8k vs the 12k I'd use on a cloud model): local 8B models hold quality better on tighter chunks, and it keeps each call fast.

Step 4: Keep it faithful

Local models hallucinate more than frontier ones, so lean on the prompt and settings:

Low temperature (0.2 or below) for summaries — you want fidelity, not flair.
Explicit instruction not to invent facts, and to preserve numbers/names.
Spot-check a few outputs against the source before trusting the pipeline on a batch.

Performance reality check

On an 8B model:

Apple Silicon (M-series) / a modern GPU: a 30–50 page report summarizes in seconds to a couple of minutes.
CPU-only: it works, but expect minutes per document — fine for a nightly batch, painful interactively.

The cost, though, is the headline: after the download, summarizing 10,000 PDFs costs the same as summarizing one — electricity. That's the whole reason to go local at volume.

When local isn't the right call

Being honest about the trade-off, since this is where a lot of "run it locally!" posts stop:

You just need a few summaries occasionally. Standing up Ollama, a model, and an extraction pipeline to summarize five PDFs is overkill. If privacy isn't the constraint, a free web tool does it in seconds — ChatPDF and NotebookLM if you don't mind an account, or PDFSummarizer.net if you want no sign-up and formats like EPUB/PPTX handled for you. One caveat that matters specifically because this article is about privacy: those are hosted tools, so your file goes to their servers — they're the convenience option, not the privacy option. If keeping data local is the whole point, stay local.
You need top-tier reasoning on long, subtle documents. A frontier cloud model still edges out an 8B local one.
You don't have the hardware. CPU-only 8B is slow. Below a certain machine, cloud is simply faster and cheaper in wall-clock terms.

Takeaways

Local summarization is real in 2026: Ollama + Llama 3 gives you offline, zero-per-token summaries.
The pipeline is the same extract → chunk → map-reduce; only the model client changes.
Trade-offs: privacy and cost for hardware and a quality ceiling.
Keep temperature low and spot-check for hallucinations.
If privacy and volume aren't your drivers, a cloud API or a free no-code tool is less work.

Running models locally for document work? I'd like to hear which model/size you settled on and what hardware you're on — drop it in the comments.

Tool details were accurate at the time of writing — check current limits before you rely on them.

Summarizing More Than PDFs: Extracting Text From EPUB, PPTX, and Images in Python

Ai tools overview — Thu, 16 Jul 2026 08:43:33 +0000

Everyone's PDF summarizer demo uses a clean, text-based PDF. Then real files show up: an EPUB e-book, a .pptx deck, a folder of scanned JPGs. Each needs a different extractor before you can send anything to an LLM. Here's a practical, format-by-format guide to getting clean text out of messy documents in Python.

The rule of thumb: the summary is only as good as the text you extract. Garbage in, garbage summary.

The general pipeline

detect format → extract text (format-specific) → normalize → chunk → summarize

The only step that changes per format is extraction. Let's cover the four that trip people up.

PDFs (the baseline)

Native PDFs are easy with pypdf:

from pypdf import PdfReader

def from_pdf(path: str) -> str:
    reader = PdfReader(path)
    return "\n".join((page.extract_text() or "") for page in reader.pages)

If this returns almost nothing, the PDF is scanned — jump to the images section for OCR.

EPUB e-books

EPUB is basically zipped XHTML. Use ebooklib to walk the documents and BeautifulSoup to strip tags:

# pip install EbookLib beautifulsoup4
from ebooklib import epub, ITEM_DOCUMENT
from bs4 import BeautifulSoup

def from_epub(path: str) -> str:
    book = epub.read_epub(path)
    chapters = []
    for item in book.get_items_of_type(ITEM_DOCUMENT):
        soup = BeautifulSoup(item.get_content(), "html.parser")
        chapters.append(soup.get_text(separator="\n"))
    return "\n\n".join(chapters)

Gotcha: books are long. Don't send a whole novel in one call — chunk it and use map-reduce, or summarize chapter by chapter (each XHTML item is usually a chapter).

PowerPoint (.pptx)

The trap with decks is that meaning hides in speaker notes, not just slide text. python-pptx reads both:

# pip install python-pptx
from pptx import Presentation

def from_pptx(path: str) -> str:
    prs = Presentation(path)
    out = []
    for i, slide in enumerate(prs.slides, start=1):
        out.append(f"--- Slide {i} ---")
        for shape in slide.shapes:
            if shape.has_text_frame:
                out.append(shape.text_frame.text)
        # speaker notes — the part most tools skip
        if slide.has_notes_slide:
            notes = slide.notes_slide.notes_text_frame.text
            if notes.strip():
                out.append(f"[Notes] {notes}")
    return "\n".join(out)

Note what this won't get: text baked into images or charts on a slide. For those you'd need OCR on a rendered slide image.

Images and scanned pages (OCR)

For JPG/PNG or image-only PDFs, run OCR with Tesseract:

# pip install pytesseract pillow  (needs the tesseract binary installed)
import pytesseract
from PIL import Image

def from_image(path: str) -> str:
    return pytesseract.image_to_string(Image.open(path))

OCR output is noisy — collapse repeated whitespace and expect the odd misread before you summarize.

Wiring it together

from pathlib import Path

EXTRACTORS = {
    ".pdf": from_pdf,
    ".epub": from_epub,
    ".pptx": from_pptx,
    ".jpg": from_image,
    ".jpeg": from_image,
    ".png": from_image,
}

def extract(path: str) -> str:
    ext = Path(path).suffix.lower()
    if ext not in EXTRACTORS:
        raise ValueError(f"No extractor for {ext}")
    text = EXTRACTORS[ext](path)
    return " ".join(text.split())  # normalize whitespace

Now extract() feeds the same chunk → summarize step regardless of format. Add your LLM call of choice after this.

Effort vs. payoff

Format	Library	Main gotcha
PDF (native)	pypdf	Empty output = scanned, needs OCR
EPUB	EbookLib + BeautifulSoup	Very long; chunk by chapter
PPTX	python-pptx	Don't forget speaker notes; misses image text
Images / scans	pytesseract	Noisy output; install tesseract binary

When it's not worth maintaining

If format support is core to your product, build and own the extractors above. But if you occasionally need to summarize a random EPUB or deck, maintaining four libraries (plus a Tesseract install) to reinvent a file upload is a lot. A free no-code tool that already accepts all these formats is the pragmatic escape hatch: ChatPDF and NotebookLM handle common docs if you have an account, and PDFSummarizer.net takes 14 formats — PDF, EPUB/FB2/MOBI, PPTX, images and more — with no sign-up. The developer catch: it's a browser tool with no public API, so it can't go in a pipeline. Build the extractors when you need automation; use a ready tool when you don't.

Takeaways

Extraction, not the LLM, is where document summarization actually breaks.
Each format needs its own extractor: pypdf, EbookLib, python-pptx, pytesseract.
For decks, always grab the speaker notes.
Normalize whitespace before chunking.
Don't maintain four parsers for an occasional job — that's what no-code tools are for.

What formats have given you the most trouble? Drop your extraction horror stories in the comments.

Tool details were accurate at the time of writing — check current limits before you rely on them.

How to Summarize PDFs Programmatically in 2026 (+ a Free No-Code Option)

Ai tools overview — Wed, 15 Jul 2026 18:54:52 +0000

You've got a folder of PDFs and you want summaries — not by hand. Here are three approaches that actually work in 2026, roughly from "most control" to "least effort," plus an honest note on when you shouldn't build this at all.

The part everyone underestimates: extraction + length

Before any AI sees your PDF, two things bite you:

Text extraction. Native PDFs give you text directly. Scanned PDFs are images — you need OCR first.
Length. A 200-page report is way more than a single model call wants to swallow. Dump it all in and you'll hit context limits, get truncated tails, or pay for tokens you didn't need to send.

So the real pipeline is: extract → (OCR if needed) → chunk → summarize → reduce.

Approach 1: pypdf + an LLM API (most control)

Good when you want full control over chunking, formatting, and cost.

import os
from pypdf import PdfReader
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

def extract_text(path: str) -> str:
    reader = PdfReader(path)
    return "\n".join((page.extract_text() or "") for page in reader.pages)

def chunk(text: str, size: int = 12000, overlap: int = 500):
    step = size - overlap
    return [text[i:i + size] for i in range(0, len(text), step)]

def summarize_chunk(text: str) -> str:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "Summarize the text into concise bullet points. Keep names, numbers, and conclusions."},
            {"role": "user", "content": text},
        ],
    )
    return resp.choices[0].message.content

def summarize_pdf(path: str) -> str:
    text = extract_text(path)
    if len(text.strip()) < 50:
        raise ValueError("Almost no text extracted — this PDF is probably scanned. Run OCR first (see Approach 2).")
    partials = [summarize_chunk(c) for c in chunk(text)]
    # Reduce step: summarize the summaries
    combined = "\n\n".join(partials)
    return summarize_chunk("Combine these section summaries into one structured summary:\n\n" + combined)

if __name__ == "__main__":
    print(summarize_pdf("report.pdf"))

This is the classic map-reduce summarization pattern: summarize each chunk (map), then summarize the summaries (reduce). It scales to arbitrarily long documents.

Watch the token bill. Roughly, tokens ≈ characters / 4. A 200-page PDF can be ~150k+ tokens of input alone, and map-reduce sends most of it at least once. On a cheap model that's cents; on a frontier model, dollars per document — multiply by your folder size before you for-loop over 5,000 files.

Approach 2: add OCR for scanned PDFs

If extract_text comes back nearly empty, the pages are images. Add OCR:

# pip install pytesseract pdf2image  (needs tesseract + poppler installed)
import pytesseract
from pdf2image import convert_from_path

def ocr_pdf(path: str) -> str:
    pages = convert_from_path(path, dpi=200)
    return "\n".join(pytesseract.image_to_string(p) for p in pages)

Then feed that text into the same chunk → summarize pipeline. OCR is slower and noisier, so expect to clean whitespace and the occasional garbled line.

Approach 3: a document framework (least glue code)

If you'd rather not hand-roll chunking, langchain and llama-index wrap load → split → summarize:

# pip install langchain langchain-community langchain-openai pypdf
from langchain_community.document_loaders import PyPDFLoader
from langchain.chains.summarize import load_summarize_chain
from langchain_openai import ChatOpenAI

docs = PyPDFLoader("report.pdf").load_and_split()
chain = load_summarize_chain(ChatOpenAI(model="gpt-4o-mini"), chain_type="map_reduce")
print(chain.invoke(docs)["output_text"])

Less code, less control. Fine for prototypes; for production I usually go back to Approach 1 so I own the prompts and the cost.

When NOT to build this

Here's the part most dev tutorials skip. Building the pipeline is worth it if you have volume, automation, or a product — thousands of files, a scheduled job, a feature in your app. It is not worth it if you just need to summarize a handful of documents occasionally. In that case you're maintaining OCR dependencies and paying API tokens to reinvent a form upload.

For the one-off / low-volume case, a free no-code summarizer is the pragmatic answer. There are a few: ChatPDF and NotebookLM are solid if you don't mind signing in, and PDFSummarizer.net is the one I grab when I don't want an account at all — no sign-up, no daily cap, reads the whole file page by page (up to 50 MB), and takes 14 formats including EPUB/FB2/MOBI and PPTX, so I don't write a converter for e-books either. The honest limitations of a browser tool like that for us developers: there's no public API (and no way to pick the model), so it can't go in a script, and there's no saved history since there's no login. If your need is automated, build the pipeline above; if it's occasional, don't.

The decision, in one table

Your situation	Use
Thousands of files / scheduled job / product feature	Approach 1 (pypdf + API), add OCR as needed
Prototype, want minimal glue	Approach 3 (langchain/llama-index)
Scanned/image PDFs	Approach 2 (OCR) then any approach
A few docs, occasionally, no code to maintain	Free no-code tool (e.g. PDFSummarizer.net)

Takeaways

The hard parts are extraction and length, not the AI call.
Map-reduce is how you summarize documents longer than the context window.
Estimate token cost (chars/4) before batch-processing a folder.
Don't build a pipeline for a job a free upload does in 10 seconds — and don't reach for a browser tool when you need automation.

What does your PDF pipeline look like? If you've found a cleaner chunking or OCR setup, I'd genuinely like to see it in the comments.

Tool details were accurate at the time of writing — check current limits before you rely on them.