A text field is indexed as analyzed terms. With our standard analyzer, text is split into tokens and lowercased. Search queries such as match analyze the input too, so input case alone usually does not prevent a match. This is different from exact keyword selection. The analyzer is fixed for this trainer; real projects can use different language and synonym processing.
Full-text matching is not substring matching. Think in terms of words, positions and allowed edits. Different queries can match the same visible page while behaving differently on other documents. Choose the query family from the requirement before tuning relevance.
- Input: TRAVEL Speaker
- Tokenize
- Lowercase: travel, speaker
- Match indexed terms
Both indexed text and match input are analyzed. Keyword values follow a different exact-value path.
Examples use the public products dataset on Elasticsearch 9.4.3. Responses are shortened JSON fragments: timing, shard and index metadata are omitted. Numeric scores are illustrative and can vary. Examples teach the method; exercise values may differ.
Search analyzed text
match is the starting point for searching a text field. The input TRAVEL is analyzed and can match Travel in name. The result is based on analyzed terms, not a case-sensitive comparison of the original JSON string. Score reflects the match in the current corpus, not a boolean confidence percentage.
For multiple input words the default operator is or: one analyzed word may be enough. That behavior is useful for broad recall but must not be confused with matching all words or a phrase. The following sections make those requirements explicit.
Try a different scenario
{
"query": {
"match": {
"name": "TRAVEL"
}
},
"size": 2,
"_source": [
"name",
"price"
]
}Elasticsearch response
{
"hits": {
"total": {
"value": 60,
"relation": "eq"
},
"hits": [
{
"_id": "3",
"_score": 1.6332386,
"_source": {
"name": "Sony Travel Speaker 3",
"price": 100
}
},
{
"_id": "13",
"_score": 1.6332386,
"_source": {
"name": "Apple Travel Speaker 13",
"price": 100
}
}
]
}
}How to read this result
The returned names contain the analyzed travel term despite the uppercase input. Compare this with a case-sensitive term query on a keyword field.
Match a phrase
match_phrase considers token positions as well as terms. With the default slop of zero, the analyzed words must be adjacent and in the same order. The example searches for gaming keyboard; a title with keyboard before gaming is a different phrase even if it has both words.
Phrase matching still analyzes text. It does not require the entire field to equal the phrase: a longer title may contain the phrase as part of its token sequence. Exact full-field equality belongs to an appropriate keyword field, not to match_phrase.
- gaming + keyboard
- Gaming Keyboard: phrase + AND
- Keyboard for Gaming: AND only
The same pair of tokens can satisfy an AND search but fail an exact phrase.
Try a different scenario
{
"query": {
"match_phrase": {
"name": "gaming keyboard"
}
},
"size": 2,
"_source": [
"name",
"price"
]
}Elasticsearch response
{
"hits": {
"total": {
"value": 30,
"relation": "eq"
},
"hits": [
{
"_id": "4",
"_score": 4.6608744,
"_source": {
"name": "Logitech Gaming Keyboard 4",
"price": 199
}
},
{
"_id": "14",
"_score": 4.6608744,
"_source": {
"name": "Samsung Gaming Keyboard 14",
"price": 199
}
}
]
}
}How to read this result
The phrase appears in the same order in matching titles. Other words before or after it do not prevent a match.
Search multiple fields
multi_match applies a text query to explicitly listed fields. Searching name and description can retrieve a product whose useful wording appears only in the description. The default best_fields strategy derives relevance from the best matching field rather than simply adding one point for each matching field.
Field names belong in a fields array. Values remain case-analyzed according to each field mapping. This trainer requires an explicit allowed list, so do not use a wildcard field selector. The returned source fields are independent from the fields searched.
Try a different scenario
{
"query": {
"multi_match": {
"query": "gaming",
"fields": [
"name",
"description"
]
}
},
"size": 2,
"_source": [
"name",
"description"
]
}Elasticsearch response
{
"hits": {
"total": {
"value": 30,
"relation": "eq"
},
"hits": [
{
"_id": "4",
"_score": 2.3304372,
"_source": {
"name": "Logitech Gaming Keyboard 4",
"description": "Reliable everyday accessory"
}
},
{
"_id": "14",
"_score": 2.3304372,
"_source": {
"name": "Samsung Gaming Keyboard 14",
"description": "Travel companion with long battery life"
}
}
]
}
}How to read this result
Inspect both returned text fields to find the source of a match. A missing word in name alone does not prove that the hit is incorrect.
Require all words
A match object can contain query and operator. Setting operator to and requires every analyzed term in that one field. In the example both travel and speaker must occur in name. The words need not be adjacent, and this is not the same as requiring the string to equal the entire product name.
Do not confuse this term-level AND with bool.must across different query clauses. Both enforce conjunction, but at different levels. When a task specifies all words in one field, a match with operator and communicates that intent directly.
Try a different scenario
{
"query": {
"match": {
"name": {
"query": "travel speaker",
"operator": "and"
}
}
},
"size": 2,
"_source": [
"name",
"price"
]
}Elasticsearch response
{
"hits": {
"total": {
"value": 30,
"relation": "eq"
},
"hits": [
{
"_id": "3",
"_score": 3.9636757,
"_source": {
"name": "Sony Travel Speaker 3",
"price": 100
}
},
{
"_id": "13",
"_score": 3.9636757,
"_source": {
"name": "Apple Travel Speaker 13",
"price": 100
}
}
]
}
}How to read this result
A name containing only travel or only speaker is excluded. Compare the total with the broader default OR version to understand the effect.
Handle a typo
Fuzziness allows a bounded number of edits between analyzed query terms and indexed terms. AUTO chooses the edit distance from term length; it does not permit arbitrary similarity. The example travle can match travel via a transposition. This technique is useful for typos, not for replacing keyword identifiers or business restrictions.
A fuzzy query still operates on analyzed words. It is not a wildcard such as an arbitrary substring pattern. More permissive search can add unwanted candidates, so introduce fuzziness only when the requirement asks for typo tolerance. In this trainer expensive scripts, wildcard and regexp queries are deliberately unavailable.
Try a different scenario
{
"query": {
"match": {
"name": {
"query": "travle",
"fuzziness": "AUTO"
}
}
},
"size": 2,
"_source": [
"name",
"price"
]
}Elasticsearch response
{
"hits": {
"total": {
"value": 60,
"relation": "eq"
},
"hits": [
{
"_id": "3",
"_score": 1.3610321,
"_source": {
"name": "Sony Travel Speaker 3",
"price": 100
}
},
{
"_id": "13",
"_score": 1.3610321,
"_source": {
"name": "Apple Travel Speaker 13",
"price": 100
}
}
]
}
}How to read this result
Matching titles use the correctly spelled travel rather than the typo. The response demonstrates bounded token correction, not substring search.
Key takeaways
- match analyzes the input; term does not.
- match_phrase requires positions and order, not full-field equality.
- multi_match lists searched fields explicitly.
- operator and requires all analyzed words within the match field.
- AUTO permits bounded edits, not arbitrary patterns.
Official reference
Ready to put this into practice?
Confirm reading to save your place. Reading and exercise progress are tracked separately in this browser using your guest cookie.