Search API now brings back photos, too.
OpenAI's Web Search API can now search images as well as text. RAG apps and agents can pull in product shots and diagrams directly, in the same single call that used to return text-only snippets.
A text-only search tool
just picked up eyes
Until now, the web_search tool in the Responses API returned nothing but text snippets and URLs. Any app that needed a photo or a diagram had to bolt on separate scraping logic or a licensed image API. OpenAI's own documentation, "Web search | OpenAI API," now spells out that setting search_content_types to include "image" makes the tool return image results as well. OpenAI's official developer account also confirmed the change in a post on X, saying apps can now search the web for images to surface products, places, visual references, and source links.
In practice, a request sets search_content_types: ["image","text"], and image_settings controls two knobs: max_results (how many images to fetch) and caption (whether to attach a short description to each image). Image results don't get mixed into the assistant's text output — they arrive in a separate web_search_call.results[] array, so an app can parse the URLs and metadata directly for display or citation.
| Web Search API before | What changed |
|---|---|
| Returned text snippets and URLs only | Also returns image URLs and captions |
| Fetching images meant separate scraping | Delivered directly in web_search_call.results[] |
| Mixing images into RAG needed extra work | Done in a single tool call |
What changed
in the settings
No more sending photos to a separate tool.
Search and citation now finish in one call.
From request to image URL
One call, two channels: text and image results come back separately.
Set content_types
Just add search_content_types: ["image","text"] to the request — image search turns on without any extra crawling code.
Images arrive separately
Image results don't get mixed into the assistant's text; they come back in a dedicated web_search_call.results[] array with URLs and captions.
Use them as-is
Pass the URLs and captions straight into your UI or RAG pipeline. The old step of crawling images separately and matching them back to the text disappears entirely.
Who benefits, and how
Engineer, marketer, designer — the same feature lands differently for each.
Engineers
The custom scraper you'd otherwise build for every image-aware RAG pipeline goes away. web_search_call.results[] can feed straight into a vector DB or a UI card, cutting both build time and maintenance surface.
Marketers
Competitor product shots and campaign visuals can be gathered with the same prompt, same call, as the text research. That shortens the prep work behind a market scan.
Designers
Moodboards and visual references can be pulled together with a chat prompt instead of a separate search tab. Copyright and usage-rights checks still need to happen the same way they always did.
Not an unqualified win
For developers whose use case is text-only, this update is close to a non-event. The documentation doesn't spell out the scope of image search, copyright handling, or rate limits in detail, so anyone wiring this into a commercial RAG app still needs to verify those on their own before shipping. It's also worth noting that Google Gemini's Search Grounding has supported multimodal input for a while — this release can fairly be read as OpenAI catching up on parity rather than opening new ground.
Three concrete next steps. (1) Start with a small image_settings.max_results and eyeball the domain spread and attribution on the returned URLs. (2) Turn on caption: true and check caption accuracy before wiring it into a production RAG pipeline. (3) Keep any existing scraping logic around for now as a fallback for rate limits or missing results — don't rip it out on day one. Jumping in on the headline alone, without checking copyright and quality, is the easiest way to get burned.