[FEATURE] WebFetch should extract text from PDFs before passing to the summarizer model

Resolved 💬 4 comments Opened Feb 6, 2026 by carrotRakko Closed Apr 4, 2026

Problem Statement

When WebFetch is given a PDF URL, it returns a response without error, but the summarizer model cannot extract actual text content from the PDF. Instead, it hallucinates plausible-sounding answers — and acknowledges the issue itself: "The PDF is heavily compressed with binary image and stream data, making precise extraction of section headings challenging without full rendering."

For PDFs over 10MB, WebFetch rejects the request with maxContentLength size of 10485760 exceeded — a limit designed for HTML pages, not PDFs where file size (images, fonts, figures) and text content are poorly correlated.

Verification:

I fetched the same 4.8MB PDF (Claude Opus 4 & Sonnet 4 System Card) via WebFetch and via curl + pdftotext + Read, asking the same question: "What is the title of this document and what are the first 3 section headings?"

| | WebFetch | curl + pdftotext + Read |
|---|---|---|
| Title | "Claude 4 System Card" | "System Card: Claude Opus 4 & Claude Sonnet 4" |
| Heading 1 | "Introduction/Overview" | "1 Introduction" |
| Heading 2 | "Capabilities and Performance" | "1.1 Model training and characteristics" |
| Heading 3 | "Safety and Responsible Scaling" | "1.1.1 Training data and process" |

WebFetch's answers are all hallucinated guesses. curl + pdftotext + Read returned the correct answers.

Proposed Solution

When WebFetch detects a PDF response (via Content-Type: application/pdf), it should extract usable content from the PDF before passing it to the summarizer model, rather than passing the raw response as-is.

For the maxContentLength limit, consider either:

  • Applying a separate, higher limit for PDFs (since file size and text content are weakly correlated), or
  • Downloading first, extracting text, then checking the text size against the limit

Alternative Solutions

Current workaround: curl the PDF to a local file, convert with pdftotext, then Read the resulting text file. This works but requires 3 tool calls and manual orchestration for something WebFetch should handle natively.

Priority: Medium - Would be very helpful

Feature Category: API and model interactions

Use Case Example

  1. Claude is researching a technical topic and encounters a PDF link (e.g., a system card, research paper, or specification document)
  2. Claude calls WebFetch with the PDF URL and a prompt
  3. Currently: the summarizer model hallucinates from binary fragments, or the request is rejected for size
  4. With this feature: text is extracted from the PDF and the summarizer model provides accurate answers, just like it does for HTML pages

Additional Context

  • The Read tool already handles local PDFs (requiring poppler-utils), so there is precedent for PDF processing within Claude Code
  • PDFs are extremely common in research, legal, financial, and enterprise contexts — exactly the workflows Opus 4.6 targets
  • A 14MB system card PDF was rejected by the 10MB limit, but its actual text content was only ~8,000 lines (~hundreds of KB)

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗