Semantic search vs keyword search, explained
Semantic search vs keyword search: what actually happens when you hit enter, how embeddings turn meaning into math, when each one wins, and why the best search runs both at once.
You type what you mean, and the search box hands back nothing. Or worse, it hands back a page that happens to share one word with your query and misses the ten that were actually about the thing you wanted. That gap between what you typed and what you meant is the whole story of modern search, and it comes down to two very different ways a search engine can work.
The short version: keyword search matches your words, semantic search matches your meaning. One is a librarian who only finds books whose spine contains your exact phrase. The other understood what you were looking for. Here's what each one is actually doing when you hit enter, when to reach for which, and why the best search boxes quietly run both.
The short answer: words vs meaning
Every search box picks a lane, and most of the ones you use every day are in the first:
- Keyword search (also called lexical or full-text search) looks for the exact words you typed, sitting somewhere in the text. Search "car" and it returns documents containing "car." It will not return one that only says "automobile," because to a keyword engine those are two unrelated strings of letters.
- Semantic search (also called meaning-based, vector, or neural search) looks for documents that are about what you typed. Search "car" and it can return the one about "automobiles," "vehicles," or "that sedan I test drove," because it compares meaning, not spelling.
Keyword search asks "do these exact words appear here?" Semantic search asks "is this passage about the same thing as my query?" That single difference is why one feels rigid and one feels like it read your mind.
How keyword search actually works
Keyword search is older, simpler, and still everywhere for good reason. When a system indexes your documents, it breaks each one into individual words (tokens), lowercases and trims them, and builds an inverted index: a big lookup table that maps every word to the list of documents it appears in. Think of the index at the back of a textbook. "Espresso" points to pages 12, 88, and 203.
When you search, the engine tokenizes your query the same way, looks each word up in that table, and returns the documents that contain them, usually ranked by a scoring formula (classic ones are TF-IDF and BM25) that rewards rare words and documents where your terms appear often.
This is genuinely great at some things:
- Exact matches. A product SKU, an error code, a person's
@handle, a legal clause. If you can quote it, keyword search finds it instantly. - Speed and transparency. Looking words up in a table is fast and cheap, and you can see exactly why a result matched.
And it falls down the moment your words and the document's words drift apart:
- Synonyms. Search "laptop," miss every document that only says "notebook."
- Paraphrase. Search "how to stop overspending," miss the article titled "the 50/30/20 rule," because they share no words.
- Vague memory. Search "that minimalist desk setup," and if the post never used those exact words, you get nothing.
Tricks that patch keyword search, but don't fix it
Engines bolt on stemming (so "running" matches "run"), synonym lists, and spell-correction to widen the net. These help, but they're hand-maintained band-aids: every synonym has to be anticipated in advance. They never capture the open-ended "these two sentences mean the same thing" that you do effortlessly.
How semantic search actually works
Semantic search throws out the assumption that matching text means matching meaning. Instead of storing your documents as words to look up, it converts each one into a list of numbers that represents what it's about. That list is called an embedding, and it's the whole trick.
From words to coordinates
An embedding model (a neural network trained on enormous amounts of text) reads a piece of text and outputs a vector: a long list of numbers, often hundreds or thousands of them. You can picture that vector as coordinates that place the text somewhere on a giant map of meaning. The model is trained so that texts about similar things land near each other on that map, and texts about different things land far apart.
So "the 50/30/20 budget rule" and "how do I spend less each month" end up as close neighbors, even though they share no words. "Espresso pre-infusion" lands in a completely different neighborhood. The words are gone; only the location, the meaning, remains.
Finding the nearest neighbors
When you search, your query runs through the same model and becomes a point on the same map. Now the engine doesn't hunt for matching words, it just measures distance: which documents landed closest to your query's point? Those nearest neighbors are your results. Closeness is usually measured with cosine similarity (the angle between two vectors) and, at scale, sped up with an approximate nearest-neighbor index inside a vector database.
That's why semantic search feels like it understands you:
- Paraphrase freely. "The recipe with the crispy tofu" finds the post that said "extra-firm, pressed and pan-fried."
- Describe the vibe. "A calm, minimalist workspace" works with no exact caption or creator name.
- Cross the language of the thing. "Ways to save money" surfaces "frugal living tips" and "cutting monthly expenses" alike.
The cost is that semantic search can be too generous. Ask it for an exact model number and it may hand you things that are merely about that product, because "close in meaning" is fuzzier than "contains this exact string." It's built for recall, not surgical precision.
Where each one wins
There's a classic trade-off hiding here, and it has names: precision (of what you returned, how much was relevant?) and recall (of everything relevant, how much did you find?).
- Keyword search is high precision, lower recall. When it matches, the match is exact and trustworthy. But it silently misses everything phrased differently.
- Semantic search is high recall, lower precision. It finds the relevant stuff your words never named, but it can also surface loosely related results you didn't want.
Put side by side, they're almost mirror images:
| What you're searching for | Keyword search | Semantic search |
|---|---|---|
| An exact product code or @handle | Yes | No |
| A phrase you can quote word for word | Yes | No |
| "How to stop overspending" | No | Yes |
| "That crispy tofu recipe" | No | Yes |
| A synonym of the word in the text | No | Yes |
| A vague, half-remembered idea | No | Yes |
Look at that table and the conclusion writes itself: you don't want to pick one. You want the row-by-row best of both.
Why the best search uses both: hybrid search
Hybrid search runs your query through keyword search and semantic search at the same time, then merges the two ranked lists into one. Exact matches from the keyword side keep precise queries sharp, and the semantic side catches everything phrased differently. The half you didn't have to think about covers the half you forgot.
The merging itself is usually done with a technique called Reciprocal Rank Fusion (RRF): instead of trying to compare a keyword relevance score against a cosine-similarity score (they're on totally different scales), it just looks at where each result ranked in each list and rewards results that both methods placed near the top. A result that's #1 for keywords and #3 for meaning beats one that only one method liked.
Where reranking fits in
Some systems add a third stage: after hybrid search narrows thousands of documents down to a shortlist, a heavier "reranker" model reads your query against each candidate and re-sorts the final handful for quality. It's slower, so it only runs on the shortlist, not the whole index. Hybrid retrieval plus a reranker is roughly the setup behind most modern AI search and retrieval (RAG) pipelines.
Where you actually run into this
You hit this trade-off most painfully in the one place you can't fix it: your own saved posts. Every native saved list (X bookmarks, Instagram Saved, TikTok Favorites) is keyword-only at best, and usually not even that, as we covered in how to search your saves in plain English. You remember the gist of what you saved, not the exact words, which is exactly the query keyword search is worst at. So the post you know you kept stays invisible.
The fix is to get your saves somewhere that keeps the full text and runs hybrid search over it. That's how Stashr is built. Its browser extension copies the whole post the moment you save it, across every platform, into one private library, then searches it with keyword and semantic ranking blended together:
stashr.search("that budgeting video from a while back");
// keyword side matches any literal words; semantic side matches the meaning
// → returns the clip even though it never says "budget"Because your saves live in one searchable copy instead of a silo per platform, one query covers everything, and because it's a real copy, link rot and deleted originals can't quietly empty your results.
Sitting on a messy pile already?
You don't need an account to start cleaning up. Our free tools can check a batch of saved links for dead ones, untangle a messy browser bookmarks file, or find the duplicates you've saved twice. No signup required.
Common questions
Is semantic search the same as AI search?
Mostly, yes, in casual use. "AI search" is a marketing umbrella, but the engine underneath it is almost always semantic search powered by embeddings, often combined with keyword search and a reranker. If a search box claims to understand natural language, it's doing some version of what's described above.
Does semantic search replace keyword search?
No, and that's the common mistake. Semantic search is worse than keyword search at exact matches: names, codes, quotes, and jargon. The winning move isn't to swap one for the other, it's to run both and blend the results. That's why hybrid search, not pure semantic, is the current default for serious systems.
What is an embedding, in one sentence?
An embedding is a list of numbers that represents the meaning of a piece of text (or an image), positioned so that similar things sit close together and different things sit far apart, which lets a computer compare meaning by measuring distance.
Do I need a vector database to do semantic search?
For a handful of documents, no: you can compare vectors directly in memory. A vector database (or a vector-capable database like Postgres with pgvector) earns its keep once you have a lot of documents, because it can find nearest neighbors quickly instead of comparing your query against every single item.
Can semantic search work on images, not just text?
Yes. The same idea extends to images: a model can embed a picture into the same kind of vector, so a text query like "the chart about interest rates" can match a screenshot with no caption. Purely visual content is the hardest case for any search, which is why an added text description of each image helps a lot.
Search everything you saved by meaning, not exact words.
Stashr copies every save across every platform, auto-tags it, and runs keyword and semantic search together. Type what you remember, get the post.
Free to start · No credit card required · Now in public beta
