Daitch-Mokotoff Soundex: How It Works, Examples & Free Calculator

What Is Daitch-Mokotoff Soundex?

Daitch-Mokotoff Soundex is a phonetic matching algorithm that converts names into six-digit codes based on their likely pronunciation. Developed by genealogists Randy Daitch and Gary Mokotoff, it was designed particularly for surnames of Slavic and Yiddish origin.

Unlike standard Soundex, which keeps the first letter followed by three digits, Daitch-Mokotoff encodes the entire name numerically. It applies rules to individual letters and letter combinations and can generate multiple codes for one name where alternative interpretations are supported.

These codes help identify surnames that may sound alike despite different spellings, making the algorithm useful for genealogical research, surname searches and record linkage. Other identifying fields are needed to determine whether two records describe the same person.

How Does Daitch-Mokotoff Soundex Work?

Daitch-Mokotoff reads a name from left to right and applies rules that convert letters and letter combinations into numeric sound codes. Unlike standard Soundex, it also encodes the first letter rather than retaining it unchanged.

1. Identify letters and combinations: longer recognised combinations are processed together rather than treating every letter separately.
2. Apply context-sensitive rules: the code can depend on whether a combination appears at the beginning of the name, before a vowel or elsewhere.
3. Generate alternatives where required: a branching implementation follows alternative encodings and can produce several codes for one name.
4. Return six-digit codes: the algorithm applies its rules for repeated sounds, retains up to six digits and pads shorter results with zeros.

For example, GOLDEN produces 583600. Its four coded sounds, G, L, D and N, produce 5836, followed by two zeros to complete the code.

A matching system compares the resulting codes to find potential phonetic matches. Implementations can differ in their branching rules, so results should be checked against the calculator or library being used.

Six-Digit Codes and Multiple Encodings

Each encoding contains six digits. Shorter results are padded with zeros, while longer results are limited to six digits. Leading zeros are significant, so codes should be stored as text rather than numbers.

For example, the code 097500 must retain its initial zero. Padding zeros complete the code; they do not represent additional sounds or indicate missing data.

Why Can One Name Produce Multiple Codes?

Some letters and letter combinations have alternative encodings under the algorithm’s rules. With branching enabled, the algorithm follows those alternatives and may return several distinct codes for the same name.

This creates more opportunities to identify spelling variations. Two names may share one code even when their other codes differ. Considering more codes can also bring unrelated names into the candidate set.

A single-code implementation and a branching implementation may therefore produce different matching results. Multiple codes represent alternative phonetic encodings, not separate identities or confidence scores.

Daitch-Mokotoff Soundex Examples

These surname pairs illustrate how different spellings can share a code. The table shows a shared code, rather than necessarily every code a branching implementation could generate.

Worked Example: LEWINSKY and LEVINSKI

In these names, W and V both encode as 7, while the internal vowels and final Y or I do not contribute digits. Both names produce the same sequence:

L → 8, W/V → 7, N → 6, S → 4, K → 5

Adding a trailing zero completes the six-digit code: 876450.

LEWINSKY and LEVINSKI share the Daitch-Mokotoff code 876450 despite their different spellings.

Example of Multiple Encodings

The final CH in AUERBACH supports alternative encodings of 5 and 4. With branching enabled, this gives 097500 and 097400. OHRBACH can produce the same alternatives.

With branching enabled, AUERBACH can produce 097500 and 097400 because CH supports alternative encodings.

These examples follow JewishGen’s Daitch-Mokotoff coding rules. Some implementations extend the branching rules, as noted in the Apache Commons Codec documentation.

Daitch-Mokotoff vs Standard Soundex

Both algorithms identify potential pronunciation-related name variations, but their coding rules differ. Daitch-Mokotoff addresses surname patterns that standard Soundex may handle poorly, including those of Slavic and Yiddish origin.

AUERBACH and OHRBACH retain different first letters under standard Soundex, so their codes cannot be identical. Daitch-Mokotoff encodes those initial vowels numerically and can give both names the shared code 097500.

A longer code does not automatically mean better matching accuracy. Test representative names and assess the useful candidates and false matches each method produces.

Daitch-Mokotoff vs Double Metaphone

Daitch-Mokotoff and Double Metaphone use different pronunciation rules and output formats. Their results should not be treated as interchangeable.

A system that checks every Daitch-Mokotoff branch may find different candidates from one that uses a single code. Similarly, comparing Double Metaphone’s primary code alone can produce different results from considering its alternate code.

Choose between them by testing genuine variations and unrelated names representative of your data. Assess whether additional candidates improve coverage without creating excessive false matches.

When Is Daitch-Mokotoff Soundex Useful?

The algorithm is useful when surnames appear with different spellings because of transcription, transliteration or historical recording practices. It is particularly relevant to names of Slavic or Yiddish origin, although its usefulness should be tested against the actual names being compared.

• Genealogical research: finding possible surname variants across historical records.
• Surname searches: returning candidates whose spelling differs from the search term.
• Record linkage: identifying potential connections between records from different sources.
• Customer deduplication: contributing phonetic evidence when surname spelling varies across systems.

It is most useful when its sound rules explain the variation. It does not translate names, establish family relationships or identify people from surnames alone.

Limitations and False Matches

Different surnames can receive the same code, a phonetic collision. Shared codes identify candidates rather than proving that records describe the same person.

• Branching expands the candidate set: multiple codes may find additional genuine variations but can also flag unrelated names.
• Pronunciation coverage is limited: the rules cannot reliably represent every language, regional accent or surname tradition.
• Some variations remain unmatched: nicknames, name changes and spelling errors that alter the encoded sounds may produce different codes.
• Six digits compress information: names with different endings may share a code once the limit is reached.
• No similarity percentage: a shared code does not express how likely records are to represent the same person.
• Implementations differ: branching rules, treatment of accented characters and input preparation can affect results.

Test known matches and non-matches from your data. Check which codes the software compares, and use other identifying fields to distinguish useful candidates from false matches.

Why a Phonetic Code Shouldn’t Decide a Match Alone

Consider records containing LEWINSKY and LEVINSKI. Their shared code 876450 makes the pair worth considering. What happens next depends on the remaining evidence:

• Matching given names and consistent contact details: phonetic agreement strengthens the case for a possible duplicate.
• Different given names and conflicting dates of birth: the records may describe different people.
• Missing identifying details: there may be insufficient evidence to decide without further review.

Even an exact address match can reflect a shared household rather than a shared identity. A reliable rule weighs the relevant fields together and allows uncertain cases to be reviewed before consolidation.

Using Daitch-Mokotoff in AdaptiveMatch™

AdaptiveMatch™ applies matching algorithms at individual-column level in WinPure Clean & Match Enterprise. Daitch-Mokotoff can be used for surname fields where its phonetic rules help identify spelling variations.

A matching rule could combine:

• Surname: Daitch-Mokotoff to identify potential phonetic agreement.
• Given name: Jaro-Winkler to assess character similarity.
• Address: WinPureFuzzy™ to compare textual variations.
• Email: exact matching to check agreement on the email value.

AdaptiveMatch™ analyses each column and recommends an algorithm and matching configuration, while allowing users to review and adjust the settings. Evidence from other fields helps distinguish potential duplicates from unrelated records.

Frequently Asked Questions

Written by

Team WinPure

The WinPure Team brings together over 100 years of combined expertise in data quality, data management, data matching, entity resolution and software innovation. Our growing team of experienced specialists combines deep industry knowledge with a passion for advancing data quality technology, helping organisations worldwide improve data accuracy, identify and resolve duplicate records, streamline operations and unlock the full potential of their data.