Fuzzy Matching Test Data: A Downloadable Dataset With Known Matches
Fuzzy matching test data is a labeled dataset built to test string-similarity logic: name records grouped by canonical identity, with each variant tagged by how it differs from the master — typo, phonetic near-miss, reordered tokens, or nickname. This free 250-row CSV ships with a data dictionary and a documented expected-match answer key.
License: As of 2026-08-02, no public license has been published for this sample dataset. License metadata is omitted until a license is published.
What fuzzy matching is — and isn't
Fuzzy matching is one technique used within entity resolution, not a synonym for it. It answers "are these two strings similar enough to be the same thing?" — entity resolution is the broader question of "do these records refer to the same real-world entity?", which can combine fuzzy matching with blocking/indexing and deterministic rules. For the full-record version of that broader question, see the duplicate customer records dataset.
Algorithm glossary
- Levenshtein distance
- The minimum number of single-character edits (insertions, deletions, substitutions) to turn one string into another.
- Jaro / Jaro-Winkler
- Similarity scores tuned for short strings like names, giving extra weight to matching prefixes (Jaro-Winkler).
- Soundex / phonetic matching
- Encodes words by how they sound rather than how they're spelled, catching phonetically similar but differently spelled names.
- Edit distance
- General term for the number of operations needed to transform one string into another (Levenshtein is one specific edit-distance metric).
- N-grams
- Overlapping substrings of length N, compared as sets — robust to reordering and partial matches.
- Token-based matching
- Splits a string into tokens (words) and compares the token sets, so word order doesn't affect the match.
- Precision / recall / similarity threshold
- The tuning tradeoff: a looser threshold catches more true matches (recall) at the cost of more false positives (precision).
Sample dataset
Representative rows from the full 250-row file (50 identity groups):
| record_id | master_id | duplicate_type | full_name | first_name | last_name | |
|---|---|---|---|---|---|---|
| 1 | 1 | MASTER | Jonathan Reyes | Jonathan | Reyes | [email protected] |
| 2 | 1 | EXACT | Jonathan Reyes | Jonathan | Reyes | [email protected] |
| 3 | 1 | TYPO_EDIT_DISTANCE | Jonathon Reyes | Jonathon | Reyes | [email protected] |
| 4 | 1 | TOKEN_REORDER | Reyes Jonathan | Jonathan | Reyes | [email protected] |
| 5 | 2 | MASTER | Catherine Smith | Catherine | Smith | [email protected] |
| 6 | 2 | PHONETIC_SOUNDEX | Katherine Smyth | Katherine | Smyth | [email protected] |
| 7 | 2 | NICKNAME_ALIAS | Cathy Smith | Cathy | Smith | [email protected] |
| 8 | 8 | NO_MATCH | Kathy Smith | Kathy | Smith | [email protected] |
Data dictionary
| Column | Type | Description |
|---|---|---|
| record_id | integer | Unique row identifier. |
| master_id | integer | ID of the canonical identity this row belongs to. All rows sharing a master_id represent the same synthetic person. |
| duplicate_type | enum (string) | MASTER, EXACT, TYPO_EDIT_DISTANCE, PHONETIC_SOUNDEX, TOKEN_REORDER, NICKNAME_ALIAS, or NO_MATCH. |
| full_name | string | Combined name as it would appear in a single-field name system. |
| first_name | string | First/given name. |
| last_name | string | Last/family name. |
| string | Synthetic email address (not a real mailbox). |
Example test cases
| Case | Detail |
|---|---|
| Exact-dup pair | record_id 2 vs record_id 1 (master_id 1). Identical strings. |
| Typo variant | "Jonathon Reyes" (record_id 3) vs "Jonathan Reyes" (record_id 1). One-character edit. |
| Token-reorder variant | "Reyes Jonathan" (record_id 4) vs record_id 1. Same tokens, different order. |
| Phonetic/Soundex variant | "Katherine Smyth" (record_id 6) vs "Catherine Smith" (record_id 5). Different spelling, same sound. |
| Nickname/alias variant | "Cathy Smith" (record_id 7) vs record_id 5. Requires an alias/nickname lookup. |
| Negative control | "Kathy Smith" (record_id 8) is its own master_id (8), not a duplicate of group 2, despite superficial similarity. |
Expected-match answer key
| record_id | duplicate_type | Matches master_id | Expected verdict | Note |
|---|---|---|---|---|
| 2 | EXACT | 1 | MATCH | Identical strings — any method, including exact equality, catches this. |
| 3 | TYPO_EDIT_DISTANCE | 1 | MATCH | Edit distance of 1; Jaro-Winkler similarity typically clears a common threshold. |
| 4 | TOKEN_REORDER | 1 | MATCH (algorithm-dependent) | Plain edit-distance scores this low; token-based/n-gram comparison is built for reordered tokens. |
| 6 | PHONETIC_SOUNDEX | 2 | MATCH | Same Soundex code; raw edit distance can be too large for edit-distance-only methods to catch. |
| 7 | NICKNAME_ALIAS | 2 | MATCH (needs alias dictionary) | Outside what edit-distance or phonetic matching alone catches. |
| 8 | NO_MATCH | 8 (self) | NO MATCH to group 2 | "Kathy" is not a standard alias of "Catherine" the way "Cathy" is — tests over-merging. |
Methodology
Generated with Generate-Data's schema builder in duplicate-generation mode: one master record per identity, then variant records tagged against it via Master ID / Duplicate Type columns. This is synthetic data — no real people, no real PII — and it's not a benchmark of any specific algorithm's accuracy; it's a labeled fixture for testing your own matching logic.
Generate a larger version
Need more rows, more identity groups, or a different variant mix? Open the schema builder → add Name/Email fields → switch on duplicate generation mode → set your duplicate rate and Duplicate Type mix → export as CSV, JSON, XML, or Parquet (JSONL/ HuggingFace also supported). AI-assisted field suggestions, if used to help design field values, are capped at 1,000 rows per batch — the duplicate-generation engine itself isn't subject to that cap.
Generate a larger fuzzy-match dataset →Frequently asked questions
What is fuzzy matching?
String-similarity matching that identifies records referring to the same thing despite differences in spelling, formatting, word order, or phonetics — using techniques like Levenshtein distance, Jaro-Winkler, or Soundex, rather than requiring an exact string match.
What's the difference between fuzzy matching and entity resolution?
Fuzzy matching is one technique used within entity resolution, not a synonym for it. Entity resolution is the broader process of deciding which records refer to the same real-world entity — it can use fuzzy matching plus blocking/indexing, deterministic rules, and other signals. See the duplicate customer records dataset for the full-record entity-resolution case.
How do I test a fuzzy matching algorithm?
Run it against a labeled dataset with a documented answer key — like the one on this page — so you can check whether your matcher correctly flags true matches (typo/phonetic/reorder variants) and correctly rejects near-miss non-matches (the negative control).