Before comparing the two approaches directly, it’s worth understanding the fundamentally different question each one is designed to answer.

Full-text search: “What best matches what I mean?”

Full-text search is designed for natural, human language. It searches within free-form text — like a product description, an article body, or a comment — and tries to find documents that are relevant to your search terms, even if the wording isn’t identical. Results aren’t simply “yes” or “no”; they’re ranked by a relevance score, so the best matches surface first.

Exact match: “Does this precise value exist?”

Exact match, by contrast, is designed for precise, structured values — like a status code, a category name, an email address, or a product SKU. It asks a strict yes-or-no question: does this field contain exactly this value, character for character? There’s no concept of “close enough” and no relevance ranking involved — a document either matches or it doesn’t.

The difference between these two search styles begins the moment data is indexed, long before any query is ever run.

How full-text (text) fields are stored

A text field’s value passes through an analyzer at index time, which breaks it into individual, normalized tokens — lowercased, split into words, sometimes reduced to a base form. It’s these tokens, not the original sentence, that Elasticsearch actually stores and searches against, which is what allows full-text search to match different word forms and capitalization patterns flexibly.

How exact-match (keyword) fields are stored

A keyword field’s value is stored exactly as it was given — no splitting, no lowercasing, no transformation of any kind. This makes it ideal for values where even a slight normalization would be undesirable, such as a specific status code where “Active” and “active” might genuinely need to be treated as different values in some systems.

flowchart TD
    A["Input Value:\n'Wireless Bluetooth Headphones'"] --> B{"Field Type?"}
    B -- "text" --> C["Analyzed into tokens:\nwireless, bluetooth, headphone"]
    B -- "keyword" --> D["Stored exactly as-is:\n'Wireless Bluetooth Headphones'"]
    C --> E["Supports flexible full-text search"]
    D --> F["Supports exact match, sorting, aggregation"]
        

Why one string value is often stored both ways at once

Because these two storage styles serve such different purposes, it’s extremely common for a single string field to be mapped both ways simultaneously — as a text field for flexible searching, and as a keyword sub-field for exact matching, sorting, or aggregating. This gives applications the freedom to choose whichever behavior fits a particular query, without having to pick just one upfront.

Storage differences carry directly into how each type of search is evaluated when a query actually runs.

Running a full-text search query

When a full-text search query comes in, the search text itself is passed through an analyzer (typically matching the one used at index time), producing its own set of tokens. Elasticsearch then compares these query tokens against the stored document tokens, calculating a relevance score for every document that shares at least one matching token — factoring in things like how often the term appears and how rare it is across the whole index.

Running an exact match query

An exact match query, by contrast, performs a direct, literal comparison between the value provided in the query and the value stored in the keyword field. There’s no tokenization, no scoring calculation, and no concept of “partial” matching — the comparison is binary, and it’s typically very fast since no relevance computation is involved.

sequenceDiagram
    participant Q1 as Full-Text Query: "wireless headphones"
    participant TextField as text field (analyzed)
    participant Q2 as Exact Query: "SKU-4471"
    participant KeywordField as keyword field (raw)
    Q1->>TextField: Analyze query into tokens
    TextField-->>Q1: Ranked, scored matches
    Q2->>KeywordField: Direct literal comparison
    KeywordField-->>Q2: Exact yes/no match
        

Relevance scoring: present in one, absent in the other

Perhaps the clearest internal distinction is that full-text search inherently involves relevance scoring — an ongoing calculation of “how well” something matches. Exact match, when used purely as a filtering condition, deliberately skips this calculation altogether, since a value either equals the target exactly or it doesn’t; there’s no meaningful notion of a “partial equality score.”

In practice, the two approaches are rarely used in isolation — most real search features combine them together.

A typical combined search flow

Consider a shopper searching an online store for “waterproof jacket,” while also having selected “In Stock” and a specific brand from a sidebar filter. The free-text portion of that request (“waterproof jacket”) is naturally handled with full-text search against a text field, while the sidebar selections (“In Stock,” a specific brand) are naturally handled with exact match conditions against keyword fields — often combined together within a single bool query, as covered in more detail elsewhere.

How results are ultimately ordered

Since exact match conditions don’t contribute a relevance score, the overall ranking of a combined search is typically driven entirely by the full-text portion — the exact match conditions simply narrow down which documents are eligible to be ranked and returned in the first place.

Each approach shines in different situations, and using the wrong one for a given field can quietly undermine your search quality or performance.

Choosing the right search style for the right purpose has security implications, particularly when enforcing access rules.

Why access control conditions belong in exact match, not full-text

When restricting search results to data a particular user is allowed to see — such as limiting results to their own account or organization — that restriction should be expressed as an exact match filter against a keyword-style field (like an account ID), not as a full-text condition. Full-text matching’s inherent flexibility, including partial and fuzzy matching behavior, makes it fundamentally unsuited to serving as a strict security boundary.

Full-text search and untrusted content

Since full-text fields commonly hold user-generated content, the same general precautions around validating and sanitizing untrusted input apply here as with any indexed text — analysis prepares content for effective searching, but it isn’t a substitute for proper content moderation or input validation.

Because full-text and exact match queries behave so differently, monitoring them often benefits from slightly different lenses.

Monitoring full-text search relevance and performance

Beyond simple latency, it’s worth tracking whether full-text searches are actually returning relevant, useful results — often through indirect signals like click-through patterns or explicit user feedback — alongside standard performance metrics like query latency and slow-query logs.

Monitoring exact match query performance

Exact match queries are typically fast and predictable, so a sudden slowdown in what should be simple filtering conditions is a strong signal worth investigating — often pointing to something like an unexpectedly large number of distinct values in a keyword field, or a missing opportunity for caching.

A few consistent patterns separate search implementations that feel accurate and fast from ones that quietly frustrate users.

These habits consistently lead to search implementations that behave exactly as intended.

Nearly every serious search feature relies on a deliberate mix of full-text and exact match behavior working together.

Yes, by mapping the field as a multi-field — a text version for full-text search alongside a keyword sub-field for exact match, sorting, and aggregation, all based on the same original value.

Full-text search is the right fit for a general search bar, since it accommodates varying phrasing, capitalization, and word forms that real users naturally type.

Exact match is the right fit, since a dropdown filter represents a precise, known value that should either match exactly or not appear at all — there’s no meaningful concept of “close enough” for a status like “Active” or “Pending.”

Generally yes, since exact match skips relevance scoring entirely and performs a simple, direct comparison, which is often cacheable as well — making it typically faster than a comparable full-text query.

This usually happens when the field was mapped as text rather than keyword, meaning the stored value was analyzed and transformed rather than kept exactly as-is, so a literal comparison against the original value no longer succeeds.

It can, particularly if the analyzer configuration doesn’t suit the content or query well, or if the search terms share no common tokens with the indexed text after analysis — reviewing the actual tokens produced on both sides is the standard way to diagnose this.

Full-text search and exact match represent two fundamentally different ways of asking Elasticsearch a question: one seeks relevance among naturally varied human language, while the other demands strict, literal precision. This distinction is built into Elasticsearch from the ground up, reflected in the difference between analyzed text fields and unanalyzed keyword fields, and carried through into how each type of query is actually evaluated internally. Recognizing which kind of question a given field or search feature is really asking — and mapping and querying it accordingly — is one of the clearest, highest-impact decisions you can make when designing search behavior that feels both accurate and fast.