Build the mental model
An analyzer is a pipeline that converts raw text into searchable tokens, both when indexing a `text` field and when running a `match` query, made up of three parts: a character filter (stripping HTML tags, for example), a tokenizer (splitting text at word boundaries), and token filters (lowercasing, stemming, removing stop words). The default `standard` analyzer splits text into words and lowercases them, so indexing "Redis Cache" produces tokens ["redis", "cache"]; typing "REDIS" into a query runs the same analyzer, turning it into ["redis"] before comparing against the inverted index — which is why a `match` query gets case-insensitive matching, because both index-time and search-time analysis run before comparison happens. Using a language-specific analyzer like `english`, which supports stemming (finding a word's root form, e.g. "running" → "run"), lets a user who types "caching" find a document containing "cache" — a `term` query, by contrast, skips the analyzer entirely and compares the raw query value directly against the indexed token (e.g. stemmed "cache"), matching only on an exact string. This is the full explanation for the mechanism promised back in Lesson 6: why `match` finds things `term` doesn't. You can think of the analyzer pipeline like a coffee-roasting process — raw beans, roast, grind, brew — where each step transforms the input into something more usable.
Connect it to a real scenario
Index the Tutorial Platform's `body` field (lesson content) with the `english` analyzer, so a user searching "caching strategies" can find documents containing any word variant ("cached", "caches", "cache") thanks to stemming. Run the `_analyze` API in Kibana's Dev Tools to preview how a given analyzer tokenizes text — verify analyzer choices this way before deploying a production mapping. Keep in mind that the default `standard` analyzer's word-boundary detection doesn't work well for languages like Burmese or Chinese, so multi-language content may need a language-specific analyzer set per field.
Try the working example
GET /_analyze
{
"analyzer": "english",
"text": "Caching Strategies for Redis"
}
# response tokens (stemmed, lowercased):
# ["cach", "strategi", "redi"]You see the input text broken into a lowercased, stemmed token array by the `english` analyzer.5-minute try-it
Run "The Quick Brown Foxes are Running" through the `_analyze` API with both `standard` and `english` analyzers, and write down how the resulting tokens differ.
One important caution
Assuming the default `standard` analyzer suits every content type without testing per field — code snippets or product SKUs can get unwanted tokens from word-splitting.
Not realizing that changing an analyzer after a mapping is deployed does not automatically rebuild the existing documents' inverted index — without reindexing, old documents won't be found by the new analyzer's tokenization.
Elasticsearch Guide — Text Analysis — Elastic