Double Metaphone

Phonetic-Encoding Fuzzy-Matching String-Matching Information-Retrieval Needs-Review

What it is

Double Metaphone is a phonetic encoding algorithm that converts a word into one or two consonant-skeleton codes representing how it sounds. Unlike most phonetic algorithms, it produces a primary code and an optional secondary code per input. The secondary code captures an alternative pronunciation — useful when a name has genuinely ambiguous phonetics or when it follows non-English phonological rules.

It was published by Lawrence Philips in 2000 in Dr. Dobb’s Journal (“The Double Metaphone Search Algorithm”) as a direct successor to his original Metaphone algorithm from 1990.

How it works

Double Metaphone reads through the input character by character, applying a large set of context-sensitive rules to emit phonetic codes. The two key advances over the original Metaphone are:

1. Dual output

Every input produces a primary code and a secondary code. For straightforward English words the two codes are identical — the algorithm only diverges when it encounters a letter combination that genuinely has two plausible readings. The secondary slot captures that alternate path rather than discarding it.

2. Non-English phonology

The rule set includes patterns from Slavic languages (Polish, Czech, and Russian transliterations), Germanic languages (German and Dutch), Celtic languages (Irish and Welsh), Italian, Spanish, and Greek. These rules are applied to romanised names — Double Metaphone does not operate on native Cyrillic, Arabic, or Chinese scripts. What it handles well is the reality of English-language name databases, which are full of transliterated surnames.

The output codes are variable-length consonant strings, as in original Metaphone. There is no fixed-width constraint.

[illustrate: side-by-side pipeline for “Garcia” — character scan annotating the initial G-rule (silent in Spanish context) forking into two code paths, primary KRS and secondary ARSS building up character by character]

Matching logic

When you encode both the query term and the indexed document, a match is declared if any of the four pairwise comparisons succeed:

query.primary   == doc.primary
query.primary   == doc.secondary
query.secondary == doc.primary
query.secondary == doc.secondary

This means two variants of a name can match even if neither returns the same primary code, as long as one of their secondaries aligns.

[illustrate: 2×2 grid showing the four comparison pairs between query and document codes, with a tick on any cell that equals a match — applied to “Garcia” vs “Karsia” as a worked example]

Example

from metaphone import doublemetaphone

doublemetaphone("Garcia")   # ('KRS', 'ARSS')
doublemetaphone("Xavier")   # ('SF', 'SFR')
doublemetaphone("Smith")    # ('SM0', 'SM0')  — identical codes
doublemetaphone("Schmidt")  # ('XMT', 'SMT')

“Garcia” illustrates the Spanish initial-G rule: in Spanish, a leading G before certain vowels is silent, so the secondary encoding drops the G entirely, yielding ARSS alongside primary KRS. A query for “Karsia” (primary KRS) would match a document indexed as “Garcia” because the primaries align.

“Xavier” shows the Spanish X-as-S/SH rule alongside a V/F consonant alternation. The primary SF and secondary SFR reflect two plausible English readings of the same Spanish-origin name.

“Smith” vs “Schmidt”: Double Metaphone encodes Schmidt as (XMT, SMT) — its secondary SMT is close to Smith’s SM0. Without dual codes, the connection between these surnames would be harder to establish.

[illustrate: step-by-step Double Metaphone encoding of “Xavier” — character scan table showing position, character, rule triggered, primary emission, secondary emission, with divergence point highlighted]

Variants and history

Philips published the original C++ source alongside the Dr. Dobb’s Journal article; ports to virtually every major language followed within a few years. The algorithm has no formal specification document beyond that article and its reference implementation, so minor behavioural differences exist between ports.

A further refinement, Metaphone 3, was published by Philips in 2009 as a commercial product claiming significantly higher accuracy on English and European names. It is not open source. For most open-source and production deployments, Double Metaphone remains the practical ceiling of the Metaphone family.

Soundex predates both by nearly a century and is far simpler — four characters, English-only, well-known to produce collisions for dissimilar names. Metaphone improved on Soundex substantially but still produced a single code. Double Metaphone’s dual-code model was the first widely adopted algorithm to treat pronunciation ambiguity as a first-class concern.

When to use it

Use Double Metaphone when:

  • You are matching personal names in a multilingual or immigrant-name corpus where spelling variation and transliteration divergence are common.
  • You need better recall than original Metaphone without moving to a fully statistical or embedding-based approach.
  • You are building a fallback or secondary-pass matcher on top of a primary lexical search.

Be aware of the Elasticsearch limitation. The analysis-phonetic plugin supports Double Metaphone via "encoder": "double_metaphone", but it indexes only the primary code by default. You gain the benefit of the more sophisticated rule set, but the dual-code matching logic is not applied — secondary codes are discarded at index time. If you need full dual-code matching in Elasticsearch, you must index both codes as separate tokens (e.g., using a custom token filter or by indexing a second field) and query across both.

{
  "filter": {
    "double_metaphone_filter": {
      "type": "phonetic",
      "encoder": "double_metaphone",
      "replace": true
    }
  }
}

Limitations to keep in mind:

  • The non-English extensions handle romanised names only. A name stored in Cyrillic or Arabic script will not encode meaningfully — normalise and transliterate first.
  • The rule set is large and heuristic. Edge cases exist, particularly for less common Central and Eastern European name patterns.
  • Phonetic matching trades precision for recall. For high-precision contexts (legal identity matching, deduplication with strict thresholds), combine Double Metaphone with an edit-distance measure to re-rank or filter candidates.
  • The algorithm is case-insensitive in practice; normalise to uppercase or lowercase before encoding to ensure consistent output across implementations.

For new implementations, Double Metaphone is the recommended default over original Metaphone. If your corpus is strictly English and performance budget is tight, original Metaphone remains adequate; for any real-world name database with international surnames, Double Metaphone’s non-English rules justify the added complexity.

See also