- 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.
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.
Related
- Multimodal inputs and generation, full examples for image, PDF, and audio, plus image generation and speech
- Files API, upload and manage stored documents in AI Studio
- Supported Models, the model catalog by endpoint
- Run Agents: Attach Files, sending files to a managed agent