Share the article
Meilisearch is typo tolerant by default, and that behavior is fully configurable: you can turn it off, restrict it to certain fields, or change how long a word has to be before a typo is forgiven.
This post explains what typo tolerance does out of the box, which settings control it, and how different configurations change the results your users see.
How does typo tolerance work by default?
Typo tolerance means Meilisearch still understands a query when it is misspelled. Left unbounded that would wreck relevancy, so it is governed by three rules based on word length:
- No typo is allowed if the query word is less than 5 characters long
- Only 1 typo is allowed if the query word is between 5 and 8 characters long
- 2 typos are allowed if the query word is 9 characters or longer
So if you are looking for lost but accidentally type last, you wouldn't get the desired result because it’s 4 characters long.
But typing greeec instead of greece would retrieve the expected documents, because it is 6 characters long, so one typo is allowed.
These are the defaults, and for most datasets they are a sensible starting point. They are also all adjustable.
How do you customize typo tolerance?
Through the index's typoTolerance setting, which controls whether typo tolerance runs at all, which fields and terms it applies to, and how long a word must be before a typo is forgiven. Every dataset is different, and the defaults will not suit all of them.
Here is the full setting, with its default values:
With that object you can:
- Disable typo tolerance entirely by setting
"enabled": false - Disable it for specific terms with
"disableOnWords", useful for brand names and product codes - Disable it on specific document attributes with
"disableOnAttributes" - Disable it on numeric tokens with
"disableOnNumbers", so123no longer matches132 - Change how long a word must be before one or two typos are forgiven, with
"minWordSizeForTypos"
For the full reference, see typo tolerance settings in the documentation.
Comparing typo tolerance settings side by side
A demo shows how different typo tolerance configurations change the returned results. You can test it here.
We will be using Hakan Özler's dataset of books. I made some changes to the original dataset for demo purposes, you can find the transformed dataset on GitHub. You can search a book by its title, ISBN (the ID of the book), author, or by the words in its description.
I have created two identical indexes with different typo tolerance settings. One index uses the out-of-the-box typo tolerance settings, whereas the other uses the following:
Typo tolerance is disabled on isbn, and typos are allowed on shorter words: one typo for words that are 2 and 3 characters long, two typos for any longer word.

It's usually better to provide the end-user with some results than with none. That’s why I set the threshold to the minimum recommended. Try typing flx and see what happens!
Sometimes, however, it is preferable to return only exact matches, for example when searching documents by a unique identifier. The ISBN is precisely that, so typo tolerance is disabled on the isbn attribute.
disableOnNumbers was added after this demo was built and is the more targeted tool for this case: it switches typo tolerance off for numeric tokens wherever they appear, so an ISBN, a SKU, or a year stops matching its own digit transpositions without you having to disable a whole attribute.
Let’s try to find a book called “Well-Grounded Rubyist” by its ISBN; type 1933988657 into the search bar.

As you can see, we get the desired book with both settings. However, we get more than one result when typo tolerance is enabled. Searching for an invalid ISBN like 1933988676 still returns results when typo tolerance is enabled; this can be confusing and misleading.
Conclusion
I didn’t disable the typo tolerance on any word because I did not deem it necessary given this dataset, did you? If you want to make some modifications and try to get more relevant results, be my guest: you can find the code on GitHub.
But, if you like real challenges, I've got one for you. Literal, an online platform for book readers, uses Meilisearch to search through bookshelves. They have been kind enough to share the recipe they've been using to deliver relevant search results:
Can you come up with a better configuration? Can you think of the perfect typo tolerance settings to enhance the relevancy?
As you may have noticed, we take user feedback very seriously. Please don’t hesitate to check our public roadmap and upvote for any feature you'd like to see in future versions or submit a new feature idea. You can also check our product repo and make a suggestion or join an existing discussion on improving the product.
Tuning typo tolerance is one part of relevancy work. If you would rather spend that time on your data than on running the engine, Meilisearch Cloud hosts it for you, with a 14-day free trial and no credit card required.
If you like Meilisearch and want to support us, a star on GitHub means a lot.
Frequently asked questions (FAQs)
What is typo tolerance in Meilisearch?
Typo tolerance lets a search still match documents when the query is misspelled. Meilisearch allows no typo on words shorter than 5 characters, one typo from 5 to 8 characters, and two typos from 9 characters up. Those thresholds are configurable per index.
How do I disable typo tolerance in Meilisearch?
Set "enabled": false in the index's typoTolerance setting to switch it off entirely. More often you want something narrower: disableOnAttributes for specific fields, disableOnWords for specific terms, or disableOnNumbers for numeric tokens.
How do I stop typo tolerance matching the wrong product codes or IDs?
Set disableOnNumbers to true so numeric tokens must match exactly, which stops 123 matching 132. If the identifier lives in its own field and contains letters too, add that field to disableOnAttributes instead.
Does typo tolerance affect ranking?
Yes, indirectly. typo is one of Meilisearch's ranking rules, applied as a bucket sort, so documents matching without typos are ranked above documents that needed one. Loosening the thresholds widens the result set rather than reshuffling exact matches.






