Make every asset searchable

The search box in your product works on some of the library. Type a query and it finds the documents, because documents are text and text is searchable. The images return nothing useful. The PDFs match only if someone happened to name them well. The audio and video are invisible, hours of content that exist in the library and cannot be found by anything except the filename someone typed at upload.

This page is for teams building a product with a mixed-asset library, a content platform, a media tool, a knowledge product, where users need to find things across formats and right now they can only really find the text.

What you have probably already tried

The usual approaches each make part of the library findable and leave the rest dark.

Filename and metadata search finds what someone remembered to name well, which is a small and shrinking fraction as the library grows. It is search over the labels, not the content, so a video whose transcript contains exactly what the user wants returns nothing unless the title happens to mention it.

Manual tagging works at first and does not scale. Every asset needs a human to describe it, tags are inconsistent between the people applying them, and the backlog grows faster than anyone tags, so coverage decays. It also only finds what the tagger thought to write down, not what is actually in the asset.

A separate tool per format is where teams end up when they get serious: a document search library, an image recognition service, a transcription vendor for audio and video, each with its own API and its own result shape. Now you maintain several integrations and a layer that merges their outputs into one result list, and the ranking across formats is your problem to solve.

Search only the text and quietly ignore the rest is the honest default a lot of products settle into. The image, audio, and video assets sit in the library as storage rather than as content, and everyone pretends the search box covers more than it does.

The shared problem is that each format is treated as a separate search problem, when what the user wants is one search across everything they have, ranked together, regardless of what kind of file the answer lives in.

How Exabase handles this

Two primitives turn a mixed library into one searchable index.

Extract turns every format into searchable text through one endpoint. Documents, images, audio, video, and web pages all go to the same place and come back as text with location references, page numbers for documents and timestamp ranges for audio and video. The image's contents become searchable, the PDF's actual text becomes searchable, the two-hour recording becomes searchable down to the moment something was said. Nothing in the library is dead weight anymore, because everything has been read into text that can be indexed.

Deep Search then searches across all of it by meaning rather than by filename or keyword, so a query finds the relevant asset whatever format it is, and returns results ranked together in one list. Because the extracted text carries location references, a hit in a video points to the timestamp and a hit in a document points to the page, so the user lands on the exact moment or passage rather than the whole file. The search matches what was meant rather than the literal words, which matters most for media, where people say things in ways nobody later types into a search box.

Stored as Resources, assets are indexed the moment they land, so extraction and search are one flow rather than two systems you connect. And it holds quality as the library grows, where naive search degrades into semantic collapse, so a library of hundreds of thousands of mixed assets stays as findable as a small one. If the library keeps growing, a Worker can process new uploads automatically so search coverage never falls behind.

What changes

The search box starts covering the whole library instead of the part that happened to be text. Every image, PDF, recording, and video becomes findable by what is actually in it, ranked alongside everything else, and the user stops needing to remember which asset holds the thing they are looking for.

The engineering change is that mixed-format search stops being several integrations plus a merge layer and becomes one pipeline. You learn one API, and the ranking across formats is handled rather than something you tune between vendors.

Which format dominates your library shapes which pattern to reach for next. Searchable podcast and audio libraries and video content search go deep on the time-based media case, and media asset management for AI covers organising and maintaining a large mixed library end to end. If you are building for a media organisation specifically, AI infrastructure for media is the sector view.

Get started

The Extract and Deep Search pages have the API detail. Media asset management for AI is the end-to-end pattern for a mixed library, and the format-specific tools, video to JSON, audio transcription, image to text, and PDF to chunks, are documented per job at tools. There is a free tier to test against your own library.

FAQs

Can I search across documents, images, audio, and video together?

Yes. Extract turns every format into searchable text through one endpoint, and Deep Search searches across all of them at once, returning results ranked together regardless of which format the answer lives in.

How do you search an image or a video?

By reading its contents into text first. Extract processes images into text and transcribes audio and video with timestamps, so the actual content becomes searchable rather than just the filename. A query then matches what is inside the asset.

Do results point to the moment in a recording, or just the file?

To the moment. Transcript chunks carry timestamp ranges, so a search result in audio or video lands on the exact point rather than the start of the file, the same way a document hit points to the page.

Does it match meaning or just keywords?

Meaning. Deep Search matches semantically, which matters most for media where the spoken or visual content rarely uses the exact words a user searches. It is hybrid, so a specific name or term still matches exactly.

Will search hold up across a large library?

Yes. It is built to hold retrieval quality at scale, where naive vector search tends to degrade into semantic collapse, so a library of hundreds of thousands of mixed assets stays searchable.

How do new uploads stay searchable?

Store them as Resources and they are indexed on arrival, or point a Worker at the library to process new uploads automatically so coverage never falls behind.

Do I need a different tool for each format?

No, that is the thing this replaces. One endpoint handles every format and one search runs across all of them, so you are not integrating a document library, an image service, and a transcription vendor and merging their results yourself.