On this page
Prefix matching is central to Algolia’s as-you-type search experience. It enables the engine to start matching records based on partial words.
For example, records containing
apricot are returned as soon as a user types
apr. There’s no need for the engine to wait for full-word match before displaying results.
This is already useful in avoiding insufficient results. But you can also use prefix matching to bring back even more results.
Algolia’s prefix search is configurable, with three available
queryType modes depending on the use case. Every index can be configured independently.
You have 3 options:
- prefixLast (default) - where only the last word is a prefix, and the rest are treated as full words
- prefixAll - where all separate text in a query is treated as a prefix
- prefixNone - disables all prefixing
Additionally, you can turn off prefixing on some attributes using:
By default, Algolia uses
prefixLast to provide an as-you-type search experience - only the last word in a query is treated as a prefix.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // Consider the following sentences. 1: "Let's play Jenga tomorrow." 2: "Check out these fighter jets flying over my town!" 3: "Beef jerky is a great source of protein." 4: "Jack and Jill went up the hill." 5: "Jacqueline bought me a jet black iPhone." // Matches for "j" are found in all five sentences. "j" ➡️ Jenga, jets, jerky, Jack, Jill, Jacqueline, jet // Matches for "je" are found in sentences 1, 2, 3 and 5. "je" ➡️ Jenga, jets, jerky, jet // The only match for "jet bl" is in sentence 5. "jet bl" ➡️ jet black
In this mode, all query words except the last one are considered complete; prefix search isn’t performed on them.
Use cases for
This is the default prefixing behavior and is encouraged for the majority of use cases.
This setting treats all query words as prefixes. Consider the last sentence from the previous example:
1 2 3 4 5 6 7 8 9 // Consider the following sentences. 1: "Let's play Jenga tomorrow." 2: "Beef jerky is a great source of protein." 3: "Check out these fighter jets flying over my town!" 4: "Jack and Jill went up the hill." 5: "Jacqueline bought me a jet black iPhone." // Matches sentences 2 and 5 "je b" ➡️ jet black, beef jerky
Sentence 2 is also returned from the query because it has “beef jerky” -
jerky matches on
beef matches on
b. Note that the order of the matched words in the result doesn’t need to be the same as the order of the prefixes in the search query. However, the order is taken into account by ranking sentence 2 below sentence 5 in the result set.
Use cases for
If users are searching in a domain where many words are commonly shortened,
prefixAll could be suitable - for example, “spec review” instead of “specification review.”
This value isn’t recommended for the majority of use cases - it yields counterintuitive results and has a negative impact on performance.
This setting treats none of a search query’s words as prefixes; all words are considered complete and only records containing matches for every query word will be returned.
Returning to the earlier examples:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 // Consider the following sentences. 1: "Let's play Jenga tomorrow." 2: "Check out these fighter jets flying over my town!" 3: "Beef jerky is a great source of protein." 4: "Jack and Jill went up the hill." 5: "Jacqueline bought me a jet black iPhone." "j" ➡️ No results. "je" ➡️ No results. "je bl" ➡️ No results. "jet bla" ➡️ No results. // Matches sentence 5 because both query words are present in the sentence. "jet black" ➡️ jet black
prefixNone isn’t recommended for most cases, because no results are displayed until entire word matches are found.
We typically recommend an instant search, as-you-type experience.
Use cases for
For a use case like searching SKUs or phone numbers in bulk (perhaps a merchandising or bulk SMS delivery tool),
prefixNone could be suitable. For example, imagine the following query in which an administrator
searches for messages that have been delivered to all three numbers:
1 "+1-867-5309 +1-123-4567 +1-555-5555"
You can adjust the prefix settings per attribute - some attributes can retain the flexibility of prefix search, and others can be more strict, allowing for only exact matches.
Use cases for
- An ecommerce shop with SKU search would only want to return exact matches. Very similar SKUs might be wildly different products, so exactness is important. It would be important to turn off prefixing on the SKU attribute while keeping prefix search for user-facing attributes like
- In the case of a phone number search, a user searching for “867-5309” doesn’t find “867-5308” relevant just because it’s one digit away. A user typing phone numbers likely already knows the full number, and suggestions would not yield more relevant results.