Fuzzy matching—also called approximate string matching or fuzzy string matching—is used by developers and data teams to match text strings during search that are similar, but not identical. When an online shopper mistypes a product name, fuzzy matching shows them near matches instead of an empty page. In healthcare, it links one patient’s records, which may vary slightly, across different systems. With fuzzy matching, the search term is matched against the closest stored string to it, not a character-for-character copy. A core data quality technique, fuzzy matching turns messy, human-entered data into reliable matches.
Key takeaways
- Fuzzy matching looks at search terms and compares them to terms that are similar but not identical—it accounts for typos, spelling differences, and messy data that exact keyword matching skips over.
- When fuzzy matching finds the mismatched but related strings, it measures the edit distance—how many small changes are required to turn one string into another.
- Different fuzzy algorithms suit different data—some match by spelling, some by sound, some by word order, and some by meaning.
- MongoDB handles fuzzy matching through MongoDB Search—it's an option you can set that runs on the database itself, so there's no separate search engine to run and keep in sync.
Table of contents
- Fuzzy matching vs. exact matching
- How does fuzzy matching work?
- What are the different types of fuzzy matching?
- Where is fuzzy matching used?
- What are the challenges of fuzzy matching?
- Best practices: How to run fuzzy matching in five steps
- How does fuzzy matching work in MongoDB?
- Where is fuzzy matching headed?
- Related resources
Fuzzy matching vs. exact matching
Most search and lookup tools work by exact matching. They look for a perfect character-for-character match of what you typed. You may have encountered this with your work email software—you search for a coworker, misspell their name, and nothing comes back even though they’re in your contacts. The tool isn’t guessing what you meant; it’s checking for an identical copy.
That’s not a flaw, it’s exact matching in action and it’s best when you correctly enter a precise value such as an account number, order number, or username. But if you’re typing a product name or a company name from memory, and miss one letter, exact matching gives zero results.
Fuzzy matching is more forgiving. Instead of asking “are these identical?” it asks “how close are these?” Fuzzy matching uses a technique called string similarity to assess two strings and count them as a match if they’re close enough. So “laptop” and “laptap” come back as a near-certain match, and the shopper still finds the product. And “Sarah Smith” and “Sara Smith” also come back because they are most likely the same person.
How does fuzzy matching work?
Fuzzy matching isn’t absolute—it doesn’t give a concrete “yes” or “no,” it answers “how close” the term is to a similar term in the database.
Here’s how it works, step by step:
Step 1: Compare text strings
The system lines up two strings—the search term and a candidate it finds in the system—and compares them:
A diner types “restarant.” The system pulls up “restaurant” as a candidate and lines the two up.
Now it can measure how far apart they are.
Step 2: Count the edits
Fuzzy matching counts how many small edits—adding, removing, or swapping a character—it would take to turn one string into another. Fewer edits mean the strings are more similar.
Turning "restarant" into "restaurant" takes a single edit—add the missing u. That's an edit distance of one.
A longer example shows how the edit count can climb: "kitten" → "sitting.”
Change the k to an s: "sitten"
Change the e to an i: "sittin"
Add a g on the end: "sitting"
That's three changes, so the edit distance is three. More edits mean a weaker match—and that edit count is what the similarity score is built from.
Counting edits this way is the Levenshtein distance—the most common fuzzy matching algorithm used today for everyday typos—and the classic form of what developers call approximate string matching. .
Step 3: Score the edits
The edit count is turned into a similarity score—usually a percentage (or a 0-to-1 score), where a higher score means the strings are more alike.
For example, one mismatched letter between two 10-letter words is a small share, so they’re about 90% similar. That same single typo in a three-letter word is a much bigger share—"cat" versus "cot" is one letter out of three—so it scores lower, around 67%, even though both are just one edit.
Step 4: Apply the cutoff
The score gets checked against cutoffs you set. Above the top one, the strings count as a match; below the bottom one, there’s no match; and anything in between gets set aside for a person to review. (This sorting is sometimes called threshold filtering.)
With the auto-match cutoff at 80%, a 90% score clears it—so the diner gets the restaurant they meant, even with the typo.
What are the different types of fuzzy matching?
There are several types of fuzzy matching, each built to solve a different problem and each running on one of a handful of fuzzy matching algorithms—character-based for spelling, phonetic for sound, token-based for word order, and semantic for meaning.
Which matching algorithm a system uses depends on the data and the difference it needs to catch—a typo, sound-alike, or name in the wrong order. The sections below break down the fuzzy matching algorithms behind each one.
Fuzzy matching techniques also split into two approaches: deterministic matching applies fixed rules—records match only if they meet set matching criteria—while probabilistic matching scores how likely a match is, which handles messier data. Most matching processes blend the two.
Fuzzy matching by characters
Character matching is the most basic kind—it counts the changes between two strings, which catches everyday typos like "Micheal"/"Michael." It's the matching algorithm most systems reach for first, and it works well when the differences are obvious spelling mistakes in short fields like names or IDs
How do character-based algorithms work?
Character-based algorithms count the changes needed to turn one string into another. The fuzzy matching algorithms in the table below differ in what counts as a change and how it's weighted, so each one suits a different kind of data.
Fuzzy matching by sound
Matching by sound, also called phonetic matching, finds a match based on how a word sounds—not how it's spelled. Type "Catherine" and the system returns "Kathryn"; type "Shawn" and it returns "Sean."
How do phonetic algorithms work?
Phonetic matching turns each word into a code based on its sound, then compares codes instead of spellings—two words that sound alike get the same code. The fuzzy matching algorithms that build that code differ in how much detail they capture:
Soundex: A solid baseline for everyday English names, the Soundex algorithm builds a short code from a word's main sounds, though it's less precise than newer methods.
Metaphone (and Double Metaphone): The Metaphone algorithm recognizes more sounds and handles unusual, non-English spellings better than Soundex. Double Metaphone goes further, giving a name more than one code when it could be pronounced more than one way—useful when a name has several plausible spellings.
Fuzzy matching by words
Sometimes words are typed into the search field in the wrong order, like “Smith, John” versus “John Smith,” or two addresses with the same information, arranged differently. For this type of search, a token-based matching method works well. It treats each word as a token and compares which words the two strings share, no matter the order.
How do token-based algorithms work?
Token-based algorithms differ in how they measure the overlap between the two sets of words:
Jaccard similarity: The Jaccard similarity algorithm counts how many words two strings share, out of all words between them. "New York City" and "New York" share two—New and York—out of three total.
Cosine similarity: Unlike Jaccard, the Cosine similarity algorithm counts how many times a word appears, not just that it's there. It turns each string into a vector—a tally of which words appear and how often—then measures the angle between them: the closer they point, the more alike the strings
Fuzzy matching by meaning
Matching by meaning, also called semantic matching, uses machine learning to look at what the words mean—not how they're spelled. "Notebook computer" and "laptop" share no letters, but they mean the same thing.
How does semantic matching work?
Semantic matching uses machine learning to turn each word into a vector—a long string of numbers that captures meaning, not spelling. The search term gets a vector too, and the system pulls the stored vectors closest to it—the idea behind vector search. Because vectors sit closer together when their meanings are alike, the closest ones match even when they share no letters, like "car" and "automobile."
Where is fuzzy matching used?
Fuzzy matching shows up anywhere data is typed by people or pulled from more than one source—where data quality and data integrity depend on connecting records that don't line up exactly.
Search: A search box has to address the typo wherever it lives—an online store, a help center, a docs site, an internal tool. This is the fuzzy search that most people see. Search "Laptap" and character matching returns laptops instead of an empty page; search "notebook computer" and semantic matching knows that's a laptop, too.
In e-commerce, fuzzy matching also powers auto-suggestions—the dropdown that forgives alternative spellings as you type, providing you with likely matching.
Healthcare: One patient often has several records across multiple systems—a hospital, clinic, and lab—under slightly different names and addresses. Linking those patient records is a record linkage job: character and phonetic matching handle the name variants, token matching the reordered addresses.
Insurance: Insurers use fuzzy matching to catch duplicate claims—the same claim filed twice under slightly different details—so each is processed once, not paid or reviewed twice.
Finance: Banks run names against a watchlist of known fraudsters as part of fraud detection, and a fraudster will spell their name a little differently to dodge an exact match. Character and phonetic matching catch the near-miss.
Matching names across languages: A name carried over from another language gets spelled more than one way—Mohammed, Muhammad, and Mohamad all point to one person. Character and phonetic matching connect those spellings; an exact match would file them as three separate people.
Reconciling records: When two companies merge, the same customer data sits at both places—spelled differently, in a different order. Character, phonetic, and token matching combine in this record linkage to merge the records automatically.
Content moderation: To get a banned word past a filter, people disguise it—a zero for an O, a doubled letter, a stray symbol. An exact match sees a new word and lets it through; character matching recognizes the banned word it's trying to hide and catches it.
What are the challenges of fuzzy matching?
Every fuzzy matching is a judgment call, and it can go wrong in either direction.
Too loose vs. too tight: The tradeoff between loose and tight has a name—precision and recall, or sensitivity and specificity.
Too loose and you get false positives—two different people merged into one record.
Too tight and you get missed matches—the same person left in the system as two.
Most systems find the right setting by adjusting the threshold over repeated rounds.
No universal threshold: The right setting depends on which mistake you can least afford.
A bank running fraud detection would rather flag a few extra names than miss one.
A store deduping its mailing list would rather miss a few duplicates than wrongly merge two customers.
Data quality: Poorly structured or inconsistent data drives up false positives and demands more data preprocessing before matching can start.
The messier the source, the lower the matching accuracy.
A problem upstream becomes a matching problem downstream, as inconsistent data and data-entry slips chip away at data accuracy until the matching catches them.
Scale: On large datasets, comparing every record against every other gets expensive fast.
A million records means a trillion comparisons, and algorithms like Levenshtein and Hamming distance consume real system resources as the data grows.
Most teams narrow the field first, grouping potential matches and running the full comparison only on records that could plausibly match.
Best practices: How to run a fuzzy match in five steps
The rest of this article is for the developer or data engineer who actually sets fuzzy matching up. The five steps below follow Ted, a data analyst at an online outdoor store. Two years of sign-ups have left his customer data full of duplicate customer records—one shopper ordered first as "Jon Smith" at "123 Main St.," then months later as "John Smith" at "123 main street."
To the system, those look like two different customer records. Before the next catalog goes out, Ted wants to find the duplicates and merge them so no one gets the catalog twice. To get it done, he uses record linkage—data cleansing and deduplication.
Step 1: Normalize the text
Ted starts by cleaning the text so formatting differences don’t read as real differences. He doesn’t fix records one at a time. He writes the rules once and runs them across the whole list: lowercase every field, drop the punctuation, and swap common abbreviations from a lookup (“St.” to “street”). The cleaned-up copy is what gets compared; the original record stays as is.
Step 2: Group the records (also called blocking)
Ted’s list contains 200,000 customer records. If he compared every record against every other, he’d be running tens of billions of checks—far more than he needs. Instead, he sorts the records into buckets and only compares records within each bucket.
He groups the records by ZIP code—every record with the same ZIP goes in the same bucket. ZIP works well because it’s stable: the same customer almost always keeps the same ZIP code, so their duplicate records stay together. Jon and John Smith share a ZIP, so they get compared, while another John Smith two states away sits in a different bucket and never gets checked against them.
Step 3: Score the matches
Inside each bucket, Ted compares the records that might be duplicates field by field, using the matching type that fits each one. For names, he uses character and phonetic matching—pairing “Jon” with “John.” Addresses are mostly lined up already from being normalized in Step 1, but if an apartment number and a street name are in a different order, token matching catches the match.
When the right type is used on each field, the comparison produces a score for the pair—how alike the two records are. The next step uses that score to decide if they’re the same customer.
Step 4: Set the thresholds
Ted now has a score for every pair, but a score alone can’t decide anything. Ted sets two cutoffs—90% and 70%—that sort every pair into one of three groups:
Above 90%—merge automatically: no human review needed.
70% to 90%—send to review: too close to reject, not close enough to merge automatically, so they are set aside for human review.
Below 70%—reject: too far apart to be the same person, so the pairing is dropped.
The two Smith records scored 96%—above his top line—so they merge automatically, no review needed.
Step 5: Review the maybes
The middle group—between Ted's two thresholds—is where the system can't decide. Ted reviews these himself: he pulls up both records and looks for something the score couldn't see, like the same email or phone number on both, then decides whether they're one customer or two.
How does fuzzy matching work in MongoDB?
MongoDB does fuzzy matching through MongoDB Search—you add one option to an ordinary search query and it starts catching typos instead of requiring an exact match.
The five steps above were a batch cleanup, matching records that already sit in a list. MongoDB Search handles the live version—catching the typo the instant someone types it into the search engine to stand up and keep in sync. Learn more about setting up MongoDB Search.
Where is fuzzy matching headed?
Fuzzy matching will always catch typos and sound-alikes, but more of the work is moving up to meaning—vector search connecting "notebook computer" to laptops—and it's getting easier to use, built into the database instead of a pipeline you build yourself. As more messy, human-entered data flows into the software we rely on, data quality work like this only matters more—getting "Sara" and "Sarah" to match.
Related resources
- What is Vector Search? — Learn how vector search matches on meaning and intent instead of exact keywords, the technique behind semantic matching.
- Full-Text Search: What It Is and How It Works — See how full-text scans whole documents through an inverted index, with fuzzy matching as one of the techniques it includes.
- What Are Vector Databases? — Explore how vector databases store and search data and index vectors for fast similarity search.
- Boolean Search — Read how Boolean search combines AND, OR, and NOT, and how the inverted index behind it powers both MongoDB's Query API and MongoDB Search.
- MongoDB Search — Discover how MongoDB Search adds fuzzy matching, autocomplete, and relevance scoring to your database, with no separate engine to run.