Embeddings are one of those AI concepts that sound boring until you realize what they actually let you build.

Search engines. Recommendation systems. Similar image search. Video search. RAG apps. Duplicate detection. Product matching. Semantic filters. Media libraries. “Find me the slide with the pricing chart.” “Show me videos where someone opens the red box.” “Find customer reviews similar to this complaint.”

That is all embeddings territory.

A normal database looks for exact matches. Embeddings help you search by meaning.

So instead of only matching the exact phrase:

red running shoes

Your app can also find:

scarlet sneakers

crimson athletic shoes

product photo of red trainers

video clip showing red shoes on a shelf

That is the fun part.

In this guide, we’ll look at text, image, and video embeddings APIs worth trying in 2026. We’ll compare what each one is good for, when to use it, and where it fits in real app workflows.

What are embeddings APIs?

An embeddings API turns content into vectors.

A vector is basically a long list of numbers that represents the meaning of the input.

For example:

“customer wants a refund” → [0.12, -0.44, 0.87, …]

Then your app can compare that vector with other vectors.

The closer two vectors are, the more similar they are.

That means you can do things like:

Input	Search result
Text query	Similar documents
Product photo	Similar products
Video clip	Similar video moments
Screenshot	Similar UI screens
Customer message	Related tickets
PDF page	Relevant report sections
Audio/video transcript	Matching knowledge base items

The important detail: not every embeddings API handles every media type.

Some are text-only. Some handle text and images. Some are built for video. Some handle text, images, video, audio, and PDFs in one shared space.

So the first question is not “which API is best?”

The first question is:

What kind of content am I trying to search?

Why we can write this guide

We’ve spent around 6 years working with AI APIs, embeddings, RAG systems, computer vision workflows, OCR pipelines, media search, and automation tools. We also checked current embedding API docs, provider pages, and recent research around multimodal retrieval.

The practical lesson is simple: embeddings are infrastructure.

Once you embed a large dataset, switching models can mean re-indexing everything. So you want to test carefully before you lock in a model for a product, search engine, or RAG pipeline.

This is especially true for multimodal search. Text, images, videos, screenshots, PDFs, and audio clips all behave differently. A model that works beautifully for support ticket search may not be good for video retrieval. A model that works well for product photos may not understand PDF layouts. Cute demo results are not enough. Test with your real data.

The quick API map

Here is the simple version before we go deeper.

API/model	Best for
OpenAI text embeddings	Text search, RAG, clustering, classification
Gemini Embedding 2	Text, image, video, audio, and PDF embeddings
Voyage Multimodal 3.5	Visual documents, screenshots, PDFs, slides, tables, videos
Cohere Embed v4	Enterprise text + image retrieval
Jina Embeddings v5 Omni	Multilingual text, image, audio, and video embeddings
Twelve Labs Marengo	Video-first embeddings and media search
Nomic Embed Vision / Multimodal	Open-source/open-weight text-image/document retrieval
OpenCLIP / SigLIP-style models	Local text-image search and visual similarity
LLMAPI	Routing and workflow layer around embedding-powered apps

Now let’s break these down by use case.

If you need text embeddings: OpenAI text embeddings

OpenAI is still one of the easiest choices for text embeddings.

Use OpenAI text embeddings when your content is mostly text:

1. Blog posts.
2. Support tickets.
3. Help center articles.
4. Product descriptions.
5. Meeting transcripts.
6. Chat messages.
7. Search documents.
8. Knowledge base chunks.
9. CRM notes.
10. Reviews and feedback.

OpenAI’s current model page for text-embedding-3-large describes it as OpenAI’s most capable embedding model for English and non-English tasks. There is also text-embedding-3-small, which is usually the better place to start when cost matters and the task is not too demanding.

What OpenAI text embeddings are good for

OpenAI text embeddings are great for classic semantic search.

Use case	Why it fits
RAG over text docs	Strong general text retrieval
Help center search	Finds meaning, not only keywords
Support ticket similarity	Groups related issues
Content recommendations	Finds related articles
Clustering	Groups similar messages or docs
Classification	Supports embedding-based classifiers
Multilingual text search	Strong non-English direction
Transcript search	Works after speech-to-text

The important note: OpenAI’s embedding models here are text embedding models. If you need direct image or video embeddings, test multimodal options like Gemini Embedding 2, Voyage, Cohere, Jina, Twelve Labs, Nomic, or CLIP-style models.

When to choose it

Choose OpenAI text embeddings if your app mostly searches text and you want a clean, mature API with strong general performance.

For example:

User question → text embedding → vector search → relevant docs → LLM answer

That is the classic RAG pattern.

If you need one API for text, image, video, audio, and PDFs: Gemini Embedding 2

Gemini Embedding 2 is one of the most important embedding APIs to try if your app handles multiple media types.

Google’s Gemini Embedding 2 documentation says the model accepts images, text, documents, audio, and video inputs and maps them into a unified semantic space. Google’s Gemini API pricing page also describes Gemini Embedding 2 as its first multimodal embedding model, mapping text, images, video, audio, and PDFs into one embedding space.

That is exactly what multimodal search needs.

What Gemini Embedding 2 is good for

Use Gemini Embedding 2 when your app needs cross-media retrieval.

Use case	Why it fits
Text-to-image search	Search images with natural language
Text-to-video search	Find video moments by description
Audio/video media search	Search across media libraries
PDF retrieval	Embed document inputs directly
Multimodal RAG	Search mixed media knowledge bases
Product discovery	Match text queries to images/videos
Enterprise search	Search across messy internal files
Multilingual workflows	Google reports broad language support

A 2026 paper, Gemini Embedding 2: A Native Multimodal Embedding Model from Gemini, introduces Gemini Embedding 2 as a native multimodal embedding model for video, audio, image, and text in one unified representation space. That research fits this section because the whole point is avoiding separate search systems for every media type.

What to watch

Check input limits before building your pipeline. Google’s docs mention PDF limits, including a maximum number of pages per file in some Gemini Embedding 2 contexts. If you want to index large PDFs, long videos, or full media archives, you may need to chunk files into pages, clips, or segments.

That is normal. Embedding large media usually means breaking it into searchable pieces.

If you need visual document embeddings: Voyage Multimodal 3.5

Voyage is especially interesting for visual documents.

The Voyage multimodal embeddings docs describe voyage-multimodal-3.5 as a rich multimodal embedding model that can vectorize interleaved text and visual data, including screenshots of PDFs, slides, tables, figures, and videos. The same docs list a 32,000-token context and adjustable embedding dimensions.

That “interleaved text and visual data” part matters a lot.

Most business documents are not clean text. They look like this:

1. Heading.
2. Paragraph.
3. Chart.
4. Screenshot.
5. Table.
6. Caption.
7. Footnote.
8. Diagram.
9. More text.
10. Another chart.

A text-only embedding model may miss the visual part. A pure image model may miss the text details. Voyage is built for the messy middle.

What Voyage Multimodal 3.5 is good for

Use Voyage when your content is visually rich.

Use case	Why it fits
PDF search	Handles visual pages better than text-only pipelines
Slide deck search	Useful for charts, layouts, and screenshots
Dashboard screenshot search	Good for mixed visual + text content
Table/figure retrieval	Better fit than plain text chunks
Multimodal RAG	Strong document retrieval layer
Visual reports	Useful for finance, analytics, research
Product manuals	Search diagrams and instructions

Voyage also supports query/document input types in its API reference, which is useful for retrieval systems because search queries and indexed documents are not always embedded the same way.

When to choose it

Choose Voyage if your app is less “search a paragraph” and more “search a document page.”

For example:

Find the slide that shows retention by customer segment.

or:

Find the PDF page with the pricing comparison table.

That is where visual document embeddings become useful.

If you need enterprise text + image retrieval: Cohere Embed v4

Cohere Embed v4 is a strong option for enterprise search and RAG workflows that include text and images.

Cohere’s Embed model docs list embed-v4.0 as a model that can turn text and images into embeddings. Cohere’s multimodal embeddings guide explains that Embed v4 can embed both images and text effectively, and Cohere’s product page describes Embed as handling noisy, multilingual, and multimodal data.

That makes it useful for company search systems where data is not clean.

What Cohere Embed v4 is good for

Use Cohere Embed v4 when you need text-image retrieval in business or enterprise products.

Use case	Why it fits
Enterprise search	Built around retrieval workflows
Product search	Maps visual assets and text into same space
RAG over mixed docs	Handles text and image inputs
Multilingual retrieval	Cohere has strong multilingual retrieval tooling
Charts and dashboards	Useful for visual business content
Search + rerank stack	Cohere’s ecosystem includes reranking
Cloud deployment choices	Available through Cohere and cloud partners

Cohere’s docs also mention input types like search_document, search_query, classification, clustering, and image for embedding workflows. That is helpful because an embedding API should support how the vector will be used, not only accept raw content.

When to choose it

Choose Cohere Embed v4 if your team cares about enterprise retrieval, multilingual search, and mixed text-image documents.

It is especially worth testing if your RAG system already uses Cohere rerankers or other Cohere models.

If you need multilingual text, image, audio, and video embeddings: Jina Embeddings v5 Omni

Jina Embeddings v5 Omni is one of the most interesting options for multilingual multimodal retrieval.

Jina’s Embedding API page says its v5 Omni models cover text, image, audio, and video in one shared embedding space. Jina’s Search Foundation API docs list jina-embeddings-v5-omni-small and jina-embeddings-v5-omni-nano as multilingual multimodal models, alongside text-only and CLIP-style options.

That gives developers a nice menu.

What Jina v5 Omni is good for

Use Jina when you want a flexible embedding family, especially across languages and modalities.

Use case	Why it fits
Multilingual semantic search	Strong focus
Text-image retrieval	Supported
Audio/video retrieval	Supported in Omni family
Cross-modal search	Shared embedding space
Lightweight model choices	Small and nano options
API-based search products	Easy to test
Multimodal classification	Works through embedding similarity

A 2026 paper, jina-embeddings-v5-omni: Geometry-preserving Embeddings via Locked Aligned Towers, describes the v5 Omni suite as models that encode text, image, audio, and video into a single semantic embedding space. The paper also explains that Jina added non-text encoders while keeping the backbone text embedding models frozen, which is useful because it keeps text embedding behavior stable while adding new modalities.

When to choose it

Choose Jina v5 Omni if your product needs multilingual multimodal search and you want text, image, audio, and video support from one model family.

It is especially useful for global apps, media search, cross-lingual search, and mixed content libraries.

If video is the main product: Twelve Labs Marengo

If your app is video-first, Twelve Labs should be on your test list.

Twelve Labs’ Marengo model docs describe Marengo as an embedding model for comprehensive video understanding that analyzes visuals, audio, and text. Their guide for creating video embeddings explains that you can configure embedding types like visual, audio, and transcription; output format like separate, fused, or both; and scope like clip or whole asset.

That is much more video-native than simply extracting transcript text and embedding it.

What Twelve Labs Marengo is good for

Use Twelve Labs when you need real video retrieval.

Use case	Why it fits
Search inside videos	Video-native embeddings
Find clips by text query	Good for media search
Video recommendations	Compare video meaning
Multimodal video understanding	Uses visual, audio, transcription signals
Clip-level retrieval	Useful for long videos
Media asset management	Search video archives
Video RAG	Retrieve relevant clips before answer generation

Twelve Labs’ API reference for text, image, and audio embeddings says the Marengo video understanding model generates embeddings for all modalities in the same latent space and supports any-to-any search across content types. That is exactly what you want if users may search videos with text, images, or other media.

When to choose it

Choose Twelve Labs if video is not just a small feature, but a core part of your product.

For example:

1. Search a video archive.
2. Find moments inside webinars.
3. Match clips to text queries.
4. Build video recommendations.
5. Analyze surveillance or sports clips.
6. Search creator content libraries.
7. Build video-based RAG.

If your videos are mostly spoken lectures and you only need exact spoken content, a speech-to-text + text embedding pipeline may be cheaper. But if visual content matters, use a video-native model.

If you want open text-image embeddings: Nomic Embed Vision and Multimodal

Nomic is worth trying when you want an open-source/open-weight direction.

The Nomic Embed Vision model card says nomic-embed-vision-v1 is a vision embedding model that shares the same embedding space as nomic-embed-text-v1. That means you can compare text and image embeddings in one space.

Nomic’s developer page also describes multimodal embeddings for search and retrieval across text, images, drawings, specs, and project documents, which makes it especially interesting for AEC, drawings, and document-heavy workflows.

What Nomic is good for

Use Nomic when you want more control than a hosted-only API gives you.

Use case	Why it fits
Text-image retrieval	Shared text/image space
Local experiments	Open model direction
Visual document search	Useful for drawings/specs direction
Product image search	Good text-image baseline
Research workflows	Inspectable model family
Custom deployment	More control than closed APIs
Open-weight preference	Strong fit

The technical report Nomic Embed Vision: Expanding the Latent Space describes Nomic Embed Vision as an open-code, open-weights image embedding model that shares the same latent space as Nomic Embed Text. That is the key idea behind cross-modal retrieval: text queries and images can be compared directly.

When to choose it

Choose Nomic if you want open model control for text-image search or visual document retrieval.

Just remember: open models can mean more engineering work. You may need to handle hosting, batching, monitoring, vector storage, and updates yourself.

If you want local image search: OpenCLIP and SigLIP-style models

OpenCLIP and SigLIP-style models are great for local text-image search.

OpenCLIP is an open-source implementation of CLIP, and the OpenCLIP GitHub repo includes pretrained models for generating text and image embeddings. CLIP-style models are useful because they put text and images into a shared embedding space.

That means:

text query → image results

image query → similar images

SigLIP-style models are also worth testing. Google’s SigLIP 2 paper presents multilingual vision-language encoders for image-text retrieval, classification, dense prediction, and visual understanding tasks.

What OpenCLIP and SigLIP-style models are good for

Use them when you want a local or open text-image search setup.

Use case	Why it fits
Similar image search	Strong baseline
Product image retrieval	Useful
Text-to-image search	Classic CLIP use case
Stock photo search	Useful
Visual recommendations	Useful
Local experiments	Strong
Open-source pipelines	Strong
Video/audio embeddings	Not the main fit

For video, you can still sample frames and embed them with CLIP-style models, but that is a workaround. If video understanding matters, test Twelve Labs, Gemini Embedding 2, Jina Omni, or another video-capable model.

When to choose it

Choose OpenCLIP or SigLIP-style models if you want local image search, visual similarity, or text-to-image retrieval without relying only on hosted APIs.

They are great for prototypes and product image search experiments.

Side-by-side comparison

Here is the practical comparison.

API/model	Text	Image	Video	Audio	PDF/docs	Best fit
OpenAI text embeddings	Yes	No	No	No	Text extracted from docs	Text RAG and semantic search
Gemini Embedding 2	Yes	Yes	Yes	Yes	Yes	Broad multimodal search
Voyage Multimodal 3.5	Yes	Yes	Video-oriented visual inputs	Not main fit	Yes	Visual documents and slides
Cohere Embed v4	Yes	Yes	No	No	Mixed text/image docs	Enterprise text-image retrieval
Jina v5 Omni	Yes	Yes	Yes	Yes	Model-family dependent	Multilingual multimodal search
Twelve Labs Marengo	Yes	Yes	Yes	Yes	Not main doc API	Video-first search
Nomic Embed Vision/Multimodal	Yes	Yes	Not main fit	Not main fit	Strong direction	Open text-image/doc retrieval
OpenCLIP/SigLIP-style	Yes	Yes	Frame workaround	No	Page image workaround	Local image search

The trick is to avoid forcing one API to do everything if your use case is specialized.

Which API should you choose for text search?

If your app mostly searches text, start simple.

Use OpenAI text embeddings, Cohere text embeddings, Jina text embeddings, Nomic text embeddings, or another strong text model.

Good text search use cases:

1. Help center search.
2. RAG over documents.
3. Support ticket similarity.
4. Review clustering.
5. Blog recommendations.
6. CRM note search.
7. Legal/finance document search after text extraction.
8. Meeting transcript retrieval.

A good text embedding workflow looks like this:

text → chunk → embed → vector database → retrieve → rerank → answer

For text-only search, a multimodal model may be unnecessary. Use a text embedding model unless images, video, audio, or layouts matter.

Which API should you choose for image search?

If your app searches images, you need text-image or image-image embeddings.

Good choices:

1. Gemini Embedding 2.
2. Cohere Embed v4.
3. Jina v5 Omni or Jina CLIP-style models.
4. Nomic Embed Vision.
5. OpenCLIP/SigLIP-style models.
6. Twelve Labs for image search inside media workflows.
7. Voyage if images are part of documents or slides.

Good image search use cases:

Use case	Good API/model direction
Product image search	OpenCLIP, Jina, Gemini, Nomic
Similar image search	OpenCLIP, Nomic, Cohere, Gemini
Visual brand search	CLIP-style + custom filters
Search screenshots	Voyage, Cohere, Gemini
Search charts/slides	Voyage, Cohere, Gemini
Multilingual image search	Jina or Gemini

For image search, test hard negatives. A hard negative is an image that looks similar but is wrong. Those examples reveal whether your embedding model understands the thing that actually matters.

Which API should you choose for video search?

If video is core, use video-native embeddings.

Good choices:

1. Twelve Labs Marengo.
2. Gemini Embedding 2.
3. Jina v5 Omni.
4. Voyage Multimodal 3.5 for visual-document/video-adjacent workflows.
5. Frame-level OpenCLIP only for simple visual matching.

Good video search use cases:

1. Search webinars by moment.
2. Find product demos.
3. Retrieve sports clips.
4. Search creator archives.
5. Build video recommendations.
6. Find clips with certain actions.
7. Search training videos.
8. Search surveillance footage.
9. Build video RAG.
10. Match short clips to longer videos.

A video search pipeline often looks like this:

video → split into clips → embed each clip → store vectors + timestamps → search → return matching moments

Do not embed a full 2-hour video as one vector and expect magic. For useful search, split long videos into clips or segments.

Which API should you choose for PDFs and visual documents?

PDFs are sneaky because they look like text files but often behave like images.

A PDF page can contain:

1. Text.
2. Tables.
3. Charts.
4. Diagrams.
5. Screenshots.
6. Scanned images.
7. Layout cues.
8. Captions.
9. Footnotes.
10. Forms.

If the document is mostly clean text, text embeddings may be enough. If layout, charts, and screenshots matter, use multimodal document embeddings.

Good choices:

1. Voyage Multimodal 3.5.
2. Gemini Embedding 2.
3. Cohere Embed v4.
4. Nomic multimodal/document direction.
5. ColPali-style visual document retrieval if you are building a custom stack.

A 2026 paper called DocRetriever argues that multimodal documents contain tables, figures, and layouts that complicate retrieval, and proposes a framework combining visual retrieval with layout-aware sparse embeddings. That fits this section perfectly because text-only chunking can lose the structure that makes a document page meaningful.

How to test embedding APIs properly

Please do not choose an embedding API from one demo.

Build a small test set.

For text:

1. 50 real user queries.
2. 200-500 candidate documents.
3. Known correct results.
4. Hard negatives.

For images:

1. Text queries.
2. Image queries.
3. Similar but wrong images.
4. Product/style/category filters.

For video:

1. Natural-language clip queries.
2. Known timestamps.
3. Similar scenes that should not match.
4. Long videos split into segments.

Track:

Metric	Why it matters
Recall@K	Is the right result in the top K?
Precision@K	Are the top results relevant?
NDCG	Are better results ranked higher?
Latency	Is search fast enough?
Cost per 1,000 items	Can you afford indexing?
Storage size	How large are vectors?
Re-indexing cost	What happens if you switch models?
Failure cases	What confuses the model?
Metadata filter quality	Does search respect product/app rules?

The boring evaluation work saves you from very expensive re-indexing later.

What should you store with embeddings?

Do not store vectors alone.

Store metadata.

For text:

Metadata	Why it helps
document_id	Link back to source
chunk_id	Show exact section
title	Display result
source_url	Cite source
created_at	Filter by freshness
permissions	Access control
language	Multilingual routing
content_type	Search by type

For images:

Metadata	Why it helps
image_url	Show result
category	Filter by product/content type
brand	Product search
color/style tags	Better filtering
license	Usage safety
owner	Access control
dimensions	Design workflows

For video:

Metadata	Why it helps
video_id	Link back to asset
start_time	Jump to moment
end_time	Show clip range
transcript_text	Hybrid search
visual_labels	Filtering
audio_labels	Filtering
scene_id	Group moments
permissions	Access control

Embeddings find similar things. Metadata makes the results usable.

Where LLMAPI fits

LLMAPI fits around embedding workflows when you need model routing, summaries, answer generation, classification, or automation after retrieval.

For example:

1. Your app embeds text, images, or video clips.
2. A vector database returns similar items.
3. LLMAPI routes the retrieved context to a model.
4. The model writes an answer, summary, recommendation, report, or review note.

Useful follow-up tasks include:

Task	Example
RAG answer	Answer using retrieved docs or media
Search explanation	Explain why results match
Content summary	Summarize top retrieved items
Metadata enrichment	Generate tags or descriptions
Report creation	Create weekly search insights
Moderation notes	Explain why a media result needs review
Product recommendations	Turn similar items into suggestions
Workflow routing	Send results to support, marketing, legal, etc.

The embedding model retrieves the right stuff. LLMAPI helps your app decide what to say or do next.

A common architecture looks like this:

content → embeddings API → vector database → retrieval → LLMAPI → answer/action

That works for RAG, media search, product discovery, enterprise search, and automation workflows.

Common mistakes when choosing embedding APIs

These are the classics.

Mistake	Better approach
Using text embeddings for images	Use multimodal or image embeddings
Embedding full videos as one vector	Split into clips/segments
Ignoring metadata	Store IDs, timestamps, permissions, tags
No hard negatives	Test similar-looking wrong examples
No reranking	Rerank top results when quality matters
Switching models too late	Test before mass indexing
Ignoring vector size	Storage cost matters
Ignoring latency	Search UX depends on speed
No access control	Filter results by permissions
Treating embeddings as answers	Use embeddings for retrieval, not final truth

The biggest mistake is choosing an API before defining the retrieval job.

The practical shortlist

Here is the shortlist we’d test first.

Project	APIs/models to try
Text RAG	OpenAI text embeddings, Cohere, Jina, Nomic
Product image search	OpenCLIP/SigLIP, Jina, Nomic, Gemini
Enterprise mixed search	Cohere Embed v4, Gemini, Voyage
PDF/page retrieval	Voyage, Gemini, Nomic, ColPali-style models
Video search	Twelve Labs Marengo, Gemini, Jina
Multilingual multimodal search	Jina v5 Omni, Gemini, Cohere
Open/local image search	OpenCLIP, SigLIP, Nomic
Media RAG	Gemini, Twelve Labs, Jina + LLMAPI

Do not test only one. Try at least three on your real data.

The takeaway

Text, image, and video embeddings APIs help apps search by meaning instead of exact words.

Use OpenAI text embeddings when your content is mostly text. Use Gemini Embedding 2 when you want one model for text, image, video, audio, and PDFs. Use Voyage Multimodal 3.5 when visual documents, screenshots, slides, and tables matter. Use Cohere Embed v4 for enterprise text-image retrieval. Use Jina v5 Omni for multilingual multimodal search across text, image, audio, and video. Use Twelve Labs Marengo when video is the main product. Use Nomic, OpenCLIP, or SigLIP-style models when you want more open/local control for text-image search.

The best setup usually looks like this:

choose embedding model → embed searchable units → store vectors + metadata → retrieve top results → rerank if needed → use LLMAPI for the final answer/action

That is how embeddings become useful in real products.

They are not the whole app. They are the layer that helps your app find the right thing fast.