Skip to main content
Use Cases
  • Choosing a model that can read the file type being sent.
  • Sending an image or a document in a model request without uploading it first.
  • Deciding between a public URL and base64 for a given provider.

This page covers which models accept files and how to shape the request. Complete examples per modality, plus image generation and audio, are owned by Multimodal inputs and generation. Files reach a model inline, as a content part in the request. There is no upload step: pass a public URL or a base64 data URI, and the AI Gateway converts it to the shape the target provider expects. Two things trip up most first requests:
  • Image support and PDF support are separate capabilities. A model that reads images very often cannot read a PDF.
  • Images and documents use different content parts, with different required fields.
Looking to store a document for reuse across knowledge bases or batch jobs? That is the Files API, a separate system. Files uploaded there cannot be referenced by ID in a model request.

Which models accept what

Of the models in the AI Gateway catalog, image input, PDF input, and audio input have meaningfully different acceptance rates — and the sets are not nested: image support does not imply PDF support.
“Vision model” does not imply “reads PDFs”. Whole families accept images without accepting PDFs, including Mistral (Pixtral, Magistral, Ministral, Mistral Medium), Llama 3.2 and Llama 4, Qwen 3.5 and 3.6, Grok 4.5 and 4.6, and Amazon Nova. Capability also varies within a family, so check the specific model rather than the family.
The modality tabs on the Models page filter by model type (chat, image generation, embedding), not by accepted input. For a model that is not in the table above, check the provider’s documentation before sending a PDF.

Sending an image vs sending a document

Images and documents are different content parts. The table shows the shape; for complete runnable examples in each language, see Multimodal inputs and generation.
input_file is not PDF-only. Anthropic models also accept CSV, plain text, JSON, Markdown, XML, and RTF as documents, and AWS Bedrock additionally accepts DOC, DOCX, XLS, XLSX, and HTML. Set filename with the correct extension so the type is detected. Bedrock rewrites document names to alphanumerics, spaces, hyphens, and brackets, truncated to 64 characters.

URL or base64?

A base64 data URI works with every provider and is the safest default. Public URLs are handled differently upstream, and the AI Gateway absorbs most of the difference: when a provider cannot fetch a URL itself, the gateway downloads the file and inlines it before forwarding the request. Two provider behaviours are worth knowing: Gemini handles files natively, and the gateway uses that. A fileUri from the Gemini Files API is passed straight through rather than downloaded. Base64 content larger than 4 MB is uploaded to the Gemini Files API automatically and sent as a fileUri, which keeps large documents out of the request body. Only arbitrary public URLs are fetched and inlined, because Gemini rejects unknown URIs with Invalid or unsupported file uri. On Vertex AI, gs:// and public URLs are both resolved server side and pass through untouched. A document file_url does not reach OpenAI. On the message path the gateway forwards file_data, file_id, and filename, so a PDF supplied as file_url arrives with no source and is ignored. Send the document as a base64 data URI in file_data, or reference an OpenAI file_id. Use base64 when the file is not reachable from the public internet, when the URL requires authentication, or when byte-identical input is needed across a fallback chain. Use a URL to keep request bodies small and to benefit from provider-side caching.
A content part a provider cannot accept may be dropped rather than rejected: the request succeeds, and the model answers without ever having seen the file. If a response ignores the attachment, confirm the model accepts that input type and that the transport is supported before debugging the prompt.