PDF and Document Input in Claude, GPT, and Gemini

Document Processing Paradigms Across Model Providers

Handling documents across modern foundation models involves distinct design choices for extracting text, interpreting layout, and managing token budgets. Anthropic Claude, OpenAI GPT, and Google Gemini each handle PDF content natively, but their underlying ingestion pipelines differ significantly in how they treat images, formatting, and supplementary office file extensions. Understanding these boundaries ensures application architectures remain resilient against payload limits and unexpected token inflation.

For PDF files, all three providers combine optical and structural analysis. Claude evaluates pages through its computer vision pipeline, turning document pages into visual inputs to parse typography, tables, and graphics. OpenAI takes a dual-stream route within its Responses API on vision models such as gpt-4o and newer systems, extracting raw text alongside page snapshots. Google Gemini similarly relies on native vision processing across documents up to 1000 pages, allowing the model to inspect charts, tabular layouts, and diagrams alongside prose.

Developers designing systems for multi-page documents need to account for how each vendor isolates text extraction from layout interpretation. When choosing between these platforms, input mechanics determine whether you should send files inline, stage them on remote object stores, or upload them to provider-hosted file buckets before triggering inference.

Ingestion Methods: Base64, URLs, and File APIs

All three vendors provide two primary transport channels: inline content blocks embedded inside the inference call, and staged uploads referenced by unique identifiers. Passing files inline via base64 encoding avoids managing file state on the provider side. However, inline base64 payloads increase transmission size and count directly against maximum HTTP request constraints, such as Anthropic’s 32 MB request ceiling.

Remote hosting via URLs is supported differently depending on the specific API endpoint. In Claude’s Messages API, developers can supply an external URL pointing directly to an online PDF inside a document source block. OpenAI allows public links using file_url within the Responses API, but external links remain unsupported in standard Chat Completions. For Gemini, developers fetch web-hosted files and upload them to the Files API before execution, or download them locally for inline transmission.

Staging files via provider-managed endpoints solves payload size issues. Staged files decouple heavy network transfers from prompt generation. With OpenAI, files are posted to /v1/files using the user_data purpose parameter, yielding a file_id for downstream requests. Gemini’s Files API accepts uploads that persist for 48 hours at zero storage cost, returning a resource URI that can be reused across interactive chat sessions.

Non-PDF File Formats and Structural Limitations

Handling files beyond standard PDFs reveals significant divergence in feature sets across the platforms. Claude does not accept binary formats like .docx or .xlsx inside document content blocks; applications must convert those assets to plain text or render them into PDF format prior to dispatch. However, text files such as .txt, .csv, and .md can be staged through Claude’s Files API using the text/plain MIME type.

OpenAI provides dedicated parsing inside the Responses API for diverse file types, including .docx, .pptx, .txt, and code files. For these rich documents and text assets, the service performs text-only extraction without capturing embedded charts or images. If an application requires diagram comprehension from a presentation or word processing document, OpenAI documentation instructs developers to compile the file to PDF first.

Spreadsheet processing under OpenAI’s Responses API uses an automated augmentation mechanism. For formats like .xlsx, .xls, .csv, .tsv, and .iif, the engine ingests only the initial 1,000 rows on each sheet. It enriches this partial view with synthetic summaries and header metadata rather than forwarding the entire workbook into the context window. Conversely, Gemini treats non-PDF inputs as standard plain text, stripping visual formatting and embedded graphics.

Provider Architectural and Operational Differences

Each provider enforces different page thresholds, request limits, and visual settings that directly affect latency and token counts. The following table contrasts key capabilities documented across the three ecosystems.

Anthropic document blocks face context constraints on dense files. Heavy typography, complex tables, or large graphics can exhaust available tokens well before hitting the 600-page limit. On Amazon Bedrock Converse API, visual PDF processing behaves differently than standard direct endpoints: visual interpretation requires citations to be explicitly turned on. Without citations enabled, Converse falls back to basic text extraction (consuming around 1,000 tokens for a 3-page document instead of roughly 7,000 tokens in visual mode).

OpenAI provides explicit resolution governance via the detail parameter on input_file items within the Responses API. Setting detail to low minimizes input token usage by processing coarse page representations, while high preserves intricate diagrams, small typefaces, and dense data points. When detail is omitted or left as auto, models starting with GPT-5.6 default to high, whereas older models default to low.

Request Implementations Across Ecosystems

Passing files directly to these APIs involves provider-specific schema fields. In Claude’s Messages API, documents reside inside a document content block alongside standard text blocks, utilizing either a URL or base64 structure.

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "messages": [{
    "role": "user",
    "content": [
      {
        "type": "document",
        "source": {
          "type": "url",
          "url": "https://assets.anthropic.com/m/1cd9d098ac3e6467/original/Claude-3-Model-Card-October-Addendum.pdf"
        }
      },
      {
        "type": "text",
        "text": "What are the key findings in this document?"
      }
    ]
  }]
}

OpenAI’s Responses API accepts document links via input_file content items. The structure cleanly separates the linked asset from the prompt instruction.

{
  "model": "gpt-6-astra",
  "input": [{
    "role": "user",
    "content": [
      {
        "type": "input_text",
        "text": "Analyze the letter and provide a summary of the key points."
      },
      {
        "type": "input_file",
        "file_url": "https://www.berkshirehathaway.com/letters/2024ltr.pdf"
      }
    ]
  }]
}

Gemini’s interaction interface handles documents by pairing a typed document block with prompt text. When sending inline base64 content, the MIME type must be declared as application/pdf.

{
  "model": "gemini-3.8-flash",
  "input": [
    {
      "type": "document",
      "data": "JVBERi0xLjQK...",
      "mime_type": "application/pdf"
    },
    {
      "type": "text",
      "text": "Summarize this document"
    }
  ]
}

Token Costs, Pricing, and Cache Considerations

Document processing token footprints vary substantially based on whether pages undergo visual rendering or text-only extraction. For instance, in Claude’s Bedrock environment, a 3-page document accounts for approximately 1,000 tokens during pure text ingestion, but jumps to around 7,000 tokens when visual rendering is active. On large documents, an addendum evaluation run might consume 45000 input tokens to produce 300 output tokens.

Token pricing directly influences the cost of running large-scale document pipelines. Verified rates as of 2026-10-01 show distinct pricing tiers across flagship and lightweight engines. Claude Opus 5.5 (claude-opus-5.5) charges $4 per 1M input tokens and $0.2 per 1M cached input tokens, with output at $20 per 1M tokens. GPT-6 Astra (gpt-6-astra) costs $10 per 1M input tokens, $1 for cached input, and $50 for output. Gemini 3.8 Flash (gemini-3.8-flash) provides a high-throughput option priced at $0.75 per 1M input tokens, $0.075 per 1M cached input tokens, and $3.75 per 1M output tokens.

Teams processing dense document batches can examine token trade-offs across model tiers using the /tools/llm-api-cost-calculator/ or inspect published baseline prices at /tools/llm-api-pricing/. Because document headers, system rules, and static appendices repeat across user sessions, prompt caching mechanisms detailed in /posts/prompt-caching-explained-claude-gpt-gemini/ can lower recurring token expenses on repeated reference files.

Production Selection and Implementation Checklist

Deploying document pipelines into production requires accounting for format compatibility, rate constraints, and downstream parsing requirements. The following checklist outlines key verification steps before rolling out an integration:

• Verify file format pre-processing: Convert Word (.docx) and PowerPoint (.pptx) assets to PDF if visual diagram comprehension is needed, or extract plain text for Claude and Gemini pipelines.
• Enforce page and payload boundaries: Confirm documents do not exceed Claude’s 600-page cap (or 100 pages for models under 1M context tokens) or Gemini’s 1000-page threshold, and keep raw payloads below 32 MB.
• Choose the appropriate transport method: Use remote URLs directly in Claude or OpenAI Responses API for web assets, or stage files via Gemini’s Files API (retained for 48 hours at zero cost).
• Audit Bedrock Converse configurations: Ensure citations are turned on if visual inspection of charts and tables is required when using Claude on Amazon Bedrock Converse API.
• Configure OpenAI resolution switches: Explicitly set detail to low to conserve tokens on text-heavy PDFs, or high when parsing dense charts and small typefaces.
• Structure output formats: When transforming PDF data into database records, pair ingestion with schema definitions as described in /posts/structured-outputs-across-claude-gpt-and-gemini-apis/.