Reference Glossary
Full-text search
Search that scans and matches words across every indexed field — filenames, captions, embedded metadata, OCR output — rather than a single tag field, returning anything containing the query term.
Why it matters in a DAM
Full-text search is what makes an old scanned brochure findable by a phrase visible in its own text, or a photo findable by a word buried in its caption rather than its keyword tags. It compensates for gaps in manual tagging by drawing on whatever raw text already sits on or around the asset, instead of requiring someone to have anticipated the exact search term as a keyword.
A worked example
Common mistake
Teams assume full-text search automatically covers OCR text pulled from images and scanned PDFs, when in most DAMs OCR has to be run and indexed as a separate step — so a scanned document with clearly visible text can still return zero results until that pipeline is switched on.
Full-text search treats every indexed field as fair game for a keyword match, rather than restricting a query to a single tag or title field. That difference matters in a DAM because assets accumulate text in places nobody tagged on purpose — a filename someone typed years ago, a caption pasted from a wire service, a description field an editor half-filled in.
The practical value shows up with legacy content. A library migrated from an old file server rarely has consistent keyword tags, but it usually has filenames and folder paths carrying real information. Full-text search picks that up without anyone re-tagging a single asset, which is often the only reason a large historical archive is searchable at all on day one.
What it does not do automatically is read the pixels of an image. Text visible on a product label, a presentation slide exported as an image, or a scanned contract only becomes searchable once OCR has extracted it and that extracted text has been fed into the same index full-text search queries against — two separate steps that are easy to assume happened when only one did.
Frequently asked
What does full-text search index that a single keyword-tag search doesn't?
Every indexed field — filenames, captions, embedded metadata, and OCR output — rather than just one tag field, so it returns anything containing the query term wherever that text happens to live on the asset.
Why is full-text search especially valuable for a legacy library migrated from an old file server?
Such a library rarely has consistent keyword tags, but it usually has filenames and folder paths carrying real information, which full-text search picks up without anyone re-tagging a single asset.
Does full-text search automatically make text inside scanned images or photos searchable?
No — text visible on a product label, a slide exported as an image, or a scanned contract only becomes searchable once OCR has extracted it and that extracted text has been fed into the same index, which is a separate step that's easy to assume already happened.
What fields does full-text search typically cover by default?
Filenames and the caption/description field are indexed by default; custom metadata fields are indexed if configured; the OCR text layer is indexed only if OCR has been run and connected to the index.
Why does full-text search compensate for gaps in manual tagging?
It draws on whatever raw text already sits on or around the asset — filename, caption, embedded metadata — instead of requiring someone to have anticipated the exact search term as a keyword tag.
What's a common mistake teams make about OCR and full-text search?
Assuming full-text search automatically covers OCR text from images and scanned PDFs, when in most DAMs OCR has to be run and indexed as a separate step — so a scanned document with clearly visible text can return zero results until that pipeline is switched on.