Cologne Phonetics: How It Works, Examples & Free Calculator

Cologne Phonetics (Kölner Phonetik) converts German names into numeric phonetic codes to help identify spelling variations. Explore its encoding rules, follow worked examples and use the free calculator to compare names.

What Is Cologne Phonetics?

Cologne Phonetics, known in German as Kölner Phonetik, is a phonetic algorithm designed for the German language. It converts text into numeric codes that help identify names with similar pronunciations despite different spellings.

Published by Hans Joachim Postel in 1969, the algorithm assigns digits to letters according to pronunciation-related rules. Some encodings depend on neighbouring letters or the letter’s position in the word.

Unlike standard Soundex, which retains the first letter followed by three digits, Cologne Phonetics produces a variable-length numeric code. It does not pad every result to a fixed length.

In name searches and record linkage, shared codes can identify candidates that exact spelling comparisons would miss. However, different names can receive the same code, so phonetic agreement should be considered alongside other identifying fields before records are linked.

How Does Cologne Phonetics Work?

Cologne Phonetics converts letters into numeric sound groups, then simplifies the resulting sequence. Some letters always receive the same digit, while others depend on their position or neighbouring letters.

The process follows four main stages:

1. Prepare the text: convert it to uppercase and normalise German umlauts. In implementations such as Apache Commons Codec, Ä, Ö and Ü become A, O and U, while ß becomes SS during uppercase conversion.
2. Encode the letters: apply the sound rules. For example, M and N encode as 6, while F, V and W encode as 3. Letters such as C require context-sensitive rules.
3. Collapse consecutive duplicate digits: reduce repeated adjacent codes to a single digit.
4. Remove vowel codes: discard 0 except when it is the first digit. The remaining sequence forms the final code.

The order of simplification matters. Duplicate digits are collapsed before vowel codes are removed, so consonants separated by a vowel can remain distinct in the final result.

Cologne Phonetics returns a variable-length code, without fixed-length padding. A matching system compares these codes to identify potential phonetic agreement; it does not receive a similarity percentage or a probability of shared identity.

Consecutive duplicate digits are collapsed before non-initial zeros are removed

Cologne Phonetics Encoding Rules

Cologne Phonetics assigns digits to letters using the rules below. Most letters have a fixed value, while C, D, T, P and X depend on their position or neighbouring letters.

Special Rules for C

• At the beginning: C becomes 4 before A, H, K, L, O, Q, R, U or X. Otherwise, it becomes 8.
• Elsewhere: C becomes 8 after S or Z. Otherwise, it becomes 4 before A, H, K, O, Q, U or X, and 8 in other cases.

Simplifying the Code

After encoding, consecutive duplicate digits are collapsed. Zeros are then removed unless they appear at the beginning. The order matters: removing a zero can leave repeated digits that remain in the final code.

Technical reference: these encoding rules follow the Apache Commons Codec Cologne Phonetic documentation.

Cologne Phonetics Worked Examples

These examples show how Cologne Phonetics converts names into numeric codes and brings some spelling variations together.

Example 1: Müller and Muller

The umlaut in Müller is normalised, so both names are processed as MULLER.

1. Encode the letters: M → 6, U → 0, L → 5, L → 5, E → 0, R → 7, producing 605507.
2. Collapse consecutive duplicate digits: 605507 becomes 60507.
3. Remove non-initial zeros: the final code is 657.

Both spellings therefore produce 657.

Different spellings can share a phonetic code without establishing that two records represent the same person.

Example 2: Schmidt

In Schmidt, C follows S, so it receives code 8. H is ignored.

1. Encode the letters: S → 8, C → 8, H → no code, M → 6, I → 0, D → 2, T → 2, producing 886022.
2. Collapse consecutive duplicate digits: 886022 becomes 8602.
3. Remove the zero: the final code is 862.

More Cologne Phonetics Examples

Keep phonetic codes as text: leading zeros are meaningful. For example, store 0172 rather than converting it to the number 172.

Cologne Phonetics vs Soundex

Cologne Phonetics is designed for German pronunciation patterns, while standard Soundex is commonly used for English-language surnames. Both group spelling variations into phonetic codes, but their encoding rules and output formats differ.

For example, Fischer produces 387 with Cologne Phonetics and F260 with standard Soundex. The codes belong to separate encoding systems and should not be compared directly.

Cologne Phonetics is a useful option when German names form a significant part of the dataset. Soundex may suit an existing surname search or a process that already relies on Soundex codes. Choose between them using results from representative names in your dataset.

Cologne Phonetics vs Double Metaphone

Cologne Phonetics focuses on German pronunciation patterns, while Double Metaphone applies rules covering a broader range of name origins. Both can identify names with similar pronunciations, but they produce different types of phonetic codes.

Cologne Phonetics is a useful candidate for datasets containing many German names. Double Metaphone may be worth testing when names come from a wider range of language backgrounds, although it does not provide reliable pronunciation matching for every language.

Comparing alternate codes can identify additional candidate pairs, but it can also introduce false matches. Check which codes your matching system actually compares when evaluating Double Metaphone.

When Is Cologne Phonetics Useful?

Cologne Phonetics is useful when German-language names may appear with different spellings across records. Comparing phonetic codes can identify candidates that an exact text comparison would miss.

• Customer deduplication: flag surname variations such as Müller and Muller for comparison alongside addresses, emails and other fields.
• Record linkage: identify potentially related records across CRM, billing and registration systems where names have been entered differently.
• Name searches: help users find records when they know how a name sounds but are unsure of its spelling.
• Historical and genealogical research: find candidate records containing spelling variations in German surnames.
• Candidate generation: use shared phonetic codes to select record pairs for more detailed comparison.

For example, a search for Muller could also return Müller because both produce 657. This broadens the search, while additional identifying information helps determine which result is relevant.

Its suitability depends on the names in your data. For datasets spanning several languages, test Cologne Phonetics against other phonetic and string comparison methods rather than applying it to every name field by default.

Cologne Phonetics Limitations and False Matches

A shared Cologne Phonetics code does not prove that two names belong to the same person. The algorithm reduces spelling information to a numeric representation, so distinct names can receive identical codes.

• Different names can share a code: phonetic grouping creates collisions. For example, Deutsch and Deutz both produce 28, but that agreement alone cannot establish a record match.
• German language focus: its rules may represent names from other language backgrounds poorly, causing missed matches or inappropriate groupings.
• Typing errors can change the code: Cologne Phonetics is not an edit-distance algorithm. A misplaced or substituted letter can produce a different result even when the intended name is clear.
• Name structure still matters: the algorithm does not identify given names, surnames, titles or particles. Additional words and changes in name order can affect the code.
• Code differences are not similarity scores: two codes that share several digits do not automatically indicate a stronger match. Numeric subtraction or percentage similarity between codes is not part of the algorithm.
• Large code groups can reduce selectivity: common codes may generate many candidate pairs, increasing comparison work and review effort.

Evaluate the algorithm using known matching and non-matching records from your own data. Review both false matches, where unrelated records are linked, and missed matches, where records for the same person receive different codes.

Why a Phonetic Code Shouldn’t Decide a Match Alone

A phonetic code describes aspects of a name’s pronunciation, not a person’s identity. Even an identical surname may belong to thousands of unrelated people. A shared Cologne Phonetics code should therefore contribute to a matching decision alongside other identifying information.

Consider these two fictional records:

The names agree phonetically, but the addresses and dates of birth differ. These records should not be automatically merged on the strength of the surname code.

A matching rule can combine phonetic name comparison with address similarity, standardised telephone numbers, email addresses or dates of birth. Consider both supporting evidence and contradictions: a missing value provides no confirmation, while a conflicting value may warrant review.

The aim is to use Cologne Phonetics to identify a plausible name variation, then assess whether the wider record supports linking the two entries.

Using Cologne Phonetics in AdaptiveMatch™

AdaptiveMatch™ within WinPure Clean & Match Enterprise supports column-level matching algorithm selection. This allows a German surname field to use Cologne Phonetics while other fields use comparisons suited to their data.

For example, a matching rule could combine:

• Surname: Cologne Phonetics to identify phonetic spelling variations.
• Address: WinPureFuzzy™ to compare textual differences.
• Email: exact matching after appropriate standardisation.

A shared surname code contributes evidence to the rule; agreement or disagreement across the other fields helps assess the candidate pair. Users can adjust the algorithms, weights and thresholds to suit their matching requirements.

Validate the combined rule on representative records before applying it to a wider dataset.

Cologne Phonetics FAQs

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.