[BUG] input_files (PDFFile) are passed as base64 via read_file tool, causing context overflow and inconsistent LLM behavior

[axelgbl]

Description

When using input_files with PDFFile (or File), CrewAI does not appear to handle the file as a native file input at the provider level.

Instead, the file is processed via the read_file tool and its content is returned as a binary/base64 representation. This content is then indirectly injected into the agent execution context.

As a result:

• The PDF is effectively treated as inline binary data (base64)
• The LLM context becomes extremely large
• Responses become inconsistent or fail due to context overflow
• The same file is re-processed during agent execution via tools

This makes PDFFile unreliable for large or even medium-sized documents.

Steps to Reproduce

1. Create a minimal CrewAI setup:

from crewai import Agent, Task, Crew
from crewai_files import PDFFile

agent = Agent(
    role="Document Analyst",
    goal="Extract structured information from PDFs",
    backstory="Expert in document analysis",
    llm="gpt-4o-mini",
)

task = Task(
    description="""
    Read the PDF document {doc}
    Extract the main sections and summarize them precisely.
    """,
    expected_output="Structured list of sections",
    agent=agent,
)

crew = Crew(agents=[agent], tasks=[task], verbose=True)

result = crew.kickoff(
    input_files={
        "doc": PDFFile(source="./src/test_crewai_files/pdfs/sample.pdf")
    }
)

print(result)

2. Run the flow:
   crewai run
3. Observe agent execution logs with verbose=True

Expected behavior

The PDF should be:

• either streamed or parsed externally before being sent to the LLM
• or converted into structured text chunks (not raw base64)

The agent should receive:

• structured text
• or extracted segments
• NOT a raw base64 PDF representation

Screenshots/Code snippets

from crewai import Agent, Task, Crew
from crewai_files import PDFFile

agent = Agent(
    role="Document Analyst",
    goal="Extract structured information from PDFs",
    backstory="Expert in document analysis",
    llm="gpt-4o-mini",
)

task = Task(
    description="""
    Read the PDF document {doc}
    Extract the main sections and summarize them precisely.
    """,
    expected_output="Structured list of sections",
    agent=agent,
)

crew = Crew(agents=[agent], tasks=[task], verbose=True)

result = crew.kickoff(
    input_files={
        "doc": PDFFile(source="./src/test_crewai_files/pdfs/sample.pdf")
    }
)

print(result)

Operating System

Ubuntu 24.04

Python Version

3.12

crewAI Version

v.1.14.4

crewAI Tools Version

v.1.14.4

Virtual Environment

Venv

Evidence

Verbose output evidence

Tool Execution Started (#3)

Tool: read_file
Args: {'file_name': 'doc'}

Tool Execution Completed (#3)

Tool Completed
Tool: read_file
Output: [Binary file: sample.pdf (application/pdf)]
Base64:
...

Possible Solution

None

Additional context

This issue blocks any production usage of PDF ingestion in multi-step CrewAI flows, because:

• context size grows linearly with file size
• multiple tasks re-trigger file expansion
• sequential workflows amplify token explosion

A safer architecture would:

• load file once
• extract structured representation once
• reuse extracted representation across tasks without re-injecting raw binary

[axelgbl]

Additional investigation

To provide more context on this issue, I performed two additional tests.

---

1. Test with an image file

I tested the exact same input_files mechanism with an image instead of a PDF:

from crewai import Agent
from crewai_files import ImageFile

agent = Agent(
    role="Image Analyst",
    goal="Analyze images",
    backstory="Expert at visual analysis",
    llm="gpt-4o",
)

result = agent.kickoff(
    messages="What's in this image?",
    input_files={
        "photo": ImageFile(
            source="./src/test_crewai_files/imgs/puppy.jpg"
        )
    },
)

print(result)

The result was perfectly correct:

"The image shows a fluffy Pomeranian dog running on grass in a park. The dog appears to be happy with its tongue out. In the background, there are some blurred cars and greenery. The sunlight adds a warm glow to the scene."

This is the image that was used:

https://static.vecteezy.com/system/resources/thumbnails/008/951/892/small/cute-puppy-pomeranian-mixed-breed-pekingese-dog-run-on-the-grass-with-happiness-photo.jpg

This suggests that multimodal handling itself is working correctly for images.

---

2. Test with a very simple PDF

I then tested with a very small and simple PDF (this PDF was used: https://github.com/mozilla/pdf.js-sample-files/blob/master/helloworld.pdf):

from crewai import Agent, Task, Crew
from crewai_files import PDFFile

agent = Agent(
    role="Document Analyst",
    goal="Analyze the content of a given PDF file.",
    backstory="Expert in document analysis",
    llm="gpt-4o",
)

task = Task(
    description="""
    Read the PDF document.
    Analyze and provide a summary of the content.
    """,
    expected_output="Structured list of sections",
    agent=agent,
)

crew = Crew(
    agents=[agent],
    tasks=[task],
    verbose=True,
)

result = crew.kickoff(
    input_files={
        "doc": PDFFile(
            source="./src/test_crewai_files/pdfs/helloworld.pdf"
        )
    }
)

print(result)

The same issue still occurs:

• the PDF is exposed through the read_file tool
• the content appears as raw Base64 binary
• the LLM does not seem to understand the document correctly
• larger PDFs quickly exceed the context window despite being reasonably sized documents

This behavior is visible in the verbose logs. I attached a screenshot of the verbose output for reference:

I also decoded the Base64 content returned by the tool. The decoded result is the raw internal PDF structure itself and contains the "Hello, world!":

%PDF-1.7

1 0 obj  % entry point
<<
  /Type /Catalog
  /Pages 2 0 R
>>
endobj

2 0 obj
<<
  /Type /Pages
  /MediaBox [ 0 0 200 200 ]
  /Count 1
  /Kids [ 3 0 R ]
>>
endobj

3 0 obj
<<
  /Type /Page
  /Parent 2 0 R
  /Resources <<
    /Font <<
      /F1 4 0 R 
    >>
  >>
  /Contents 5 0 R
>>
endobj

4 0 obj
<<
  /Type /Font
  /Subtype /Type1
  /BaseFont /Times-Roman
>>
endobj

5 0 obj  % page content
<<
  /Length 44
>>
stream
BT
70 50 TD
/F1 12 Tf
(Hello, world!) Tj
ET
endstream
endobj

xref
0 6
0000000000 65535 f 
0000000010 00000 n 
0000000079 00000 n 
0000000173 00000 n 
0000000301 00000 n 
0000000380 00000 n 
trailer
<<
  /Size 6
  /Root 1 0 R
>>
startxref
492
%%EOF

This seems to confirm that the PDF is injected as raw binary content rather than as extracted text or multimodal document content understandable by the LLM.

[w2jmoe]

Interesting report 👋

This feels like a broader agent-runtime pattern we've been seeing lately:

large files enter the workflow as “tool outputs”, then repeatedly expand into context across downstream steps, which turns tool execution into accidental token amplification.

Especially in multi-step agent systems, the problem often isn't the PDF itself — it's that the runtime lacks a routing / budgeting layer deciding:

• when a tool result should stay external
• when it should be summarized
• when it should be cached
• and when re-execution is actually unnecessary

The repeated read_file → base64 → reinjection loop can quietly become a massive context sink 🥲

Very interesting issue. Curious to see where CrewAI lands architecturally on this.

[smqd19]

This issue with inlining PDFs as base64 strings into the LLM context is a classic pitfall that kills efficiency and causes token bloat. We ran into a similar problem when building a RAG system with document ingestion at scale. Instead of embedding the entire PDF content in the prompt, it's better to preprocess and chunk the PDF outside the LLM context using a tool like PyMuPDF or pdfplumber. Then, you can embed or index those chunks with a vector DB (e.g., Pinecone, FAISS) and only pass relevant text snippets to the model during runtime. Another workaround could be to have the agent call an external retrieval tool or API that reads the PDF on demand rather than embedding the file itself. This keeps your context size manageable and avoids reprocessing the file multiple times.

[axelgbl]

It’s funny that you mention this approach @smqd19, because it’s exactly the workaround I ended up implementing myself.

I currently preprocess PDFs outside of CrewAI using pdfplumber (or OCR pipelines for scanned PDFs with pdf2image + cv2 + pytesseract), then store the extracted content in S3 storage. Whenever I need to call an LLM with these documents as inputs, I retrieve the extracted text from S3 and inject only the relevant content into the agent prompt.

That said, I still find it unfortunate that CrewAI’s native input_files feature does not properly support PDFs in this scenario, because the workaround introduces several drawbacks:

• verbose=True becomes almost unusable since the entire document content gets dumped into the logs. (I found a workaround for that using CrewAI event listeners).
• Sending the full extracted document directly into the prompt still feels inefficient and unnecessarily expensive from a token/context perspective.
• The overall code becomes significantly less clean and less declarative than simply relying on native file support.

What surprised me most is that multimodal handling itself seems to work correctly for images, but PDFs are apparently treated as raw binary payloads rather than true document inputs.

Regarding your suggestion about vector databases: in my specific use case, I do not need semantic search or retrieval across documents. I mainly need deterministic access to already extracted content. Because of that, S3 storage has been sufficient so far.

Do you think introducing a vector DB would still make sense in this context, or would it mostly add unnecessary complexity if semantic retrieval is not required?

Thanks for your insights on the issue!
I’m really curious to see how the input_files feature evolves in future CrewAI releases. 😀

[norika1207-lab]

One practical way to make this easier to evaluate is to turn the report into a small contract test around the runtime boundary, not only the user-facing symptom.

For PDFFile passed as base64 causing context overflow, I would check three things: first, the failing input is preserved as a minimal fixture; second, the SDK emits the same observable event/result shape before and after the fix except for the intended change; third, the trace or serialized session contains enough metadata to explain what happened after a resume or retry.

The part that matters for agent systems is durability: if a tool call, memory write, handoff, or structured-output step fails, downstream code should not have to infer state from natural-language output. A focused regression test around that boundary would make the issue much easier to close with confidence.

[axelgbl]

Thanks for the suggestion @norika1207-lab.

I may be misunderstanding your point, but I'm not entirely sure what additional information or validation you would expect from my side.

The issue already includes:

• a minimal reproducible example,
• a minimal PDF fixture (helloworld.pdf),
• verbose execution traces showing the read_file tool returning a Base64 representation,
• and the expected behavior (PDF content being processed as document/text content rather than injected as raw binary).

If your suggestion is that CrewAI should add a regression or contract test around this runtime boundary when implementing a fix, I completely agree. However, I'm not sure what additional artifact or test case you think is currently missing from the report itself. Could you clarify what specific validation you would like to see added?