Levenshtein Distance Calculator

The calculator uses the Wagner–Fischer dynamic-programming algorithm, the standard method for computing the Levenshtein (edit) distance defined by Vladimir Levenshtein in 1966. Given two strings A of length m and B of length n, it fills a table of size (m+1) × (n+1) where each cell d[i][j] holds the edit distance between the first i characters of A and the first j characters of B. Every cell is solved exactly once and reused, which is what turns an exponential search over edit scripts into a quadratic table fill.

1. Apply the pre-processing toggles first: lowercase both strings if the comparison is case-insensitive, and strip whitespace if that option is on. Whitespace is stripped before case folding, so both toggles can be combined safely.
2. Initialise the edges: d[i][0] = i (turning a prefix into an empty string costs i deletions) and d[0][j] = j (building from empty costs j insertions).
3. Fill each remaining cell with the recurrence below, where the substitution cost is 0 when the characters match and 1 when they differ:

   cost = (A[i-1] == B[j-1]) ? 0 : 1
   d[i][j] = min(
     d[i-1][j]   + 1,   // deletion
     d[i][j-1]   + 1,   // insertion
     d[i-1][j-1] + cost // substitution / match
   )

4. The Levenshtein distance is the bottom-right cell, d[m][n].
5. Backtrack from d[m][n] to d[0][0], at each step choosing the predecessor that produced the minimum, to recover one optimal edit script and the per-operation counts. Ties are broken in a fixed, documented order: match, substitution, deletion, insertion.

Cost model and why it matters

All three operations carry unit cost here — one insertion, one deletion, and one substitution each add 1. That is the classical definition, and it is what almost every library means by “Levenshtein distance.” Variants change those weights: a substitution cost of 2 makes the metric equivalent to the longest common subsequence, and Damerau–Levenshtein adds a fourth operation, transposition of two adjacent characters, at cost 1. Under the unit-cost model used on this page, the transposition form → from costs 2, not 1, because it is recorded as two substitutions. If a library gives you a different number than this tool, the cost model is the first thing to check.

Bounds every result satisfies

The distance is a true metric, so three properties always hold: d(A, A) = 0, d(A, B) = d(B, A), and the triangle inequality d(A, C) ≤ d(A, B) + d(B, C). Two bounds follow directly from the recurrence and are useful as sanity checks on any implementation: |m − n| ≤ d(A, B) ≤ max(m, n). The lower bound holds because every length difference needs at least one insertion or deletion; the upper bound holds because you can always substitute across the shared prefix length and then insert or delete the remainder. If a result ever falls outside that range, the implementation is wrong.

Edge cases this tool handles explicitly

• Both strings empty. Distance 0. The similarity denominator max(m, n) would be zero, so similarity is defined as 100% rather than left undefined.
• One string empty.The distance equals the other string’s length — every character is an insertion. That is the upper bound above, hit exactly.
• Unicode beyond ASCII.JavaScript compares strings by UTF-16 code unit, not by perceived letter. A Sinhala consonant carrying a vowel sign is two code points, and an emoji outside the Basic Multilingual Plane is two code units, so both count as two “characters” in the matrix. This is the same convention used by most standard-library implementations, and it is why the similarity denominator can look larger than the number of glyphs you see. If you are comparing legacy Sinhala text, normalise it with the Sinhala Unicode converter first — a legacy-font string and its Unicode equivalent look identical on screen but share almost no code points, which produces a huge and meaningless distance.
• Very long inputs. Each field is capped at 2,000 characters, which bounds the table at roughly four million cells and keeps the computation instant and entirely client-side. Above 40 characters on either side the matrix render collapses to protect the DOM; the distance itself is unaffected.

The algorithm runs in O(m × n) time and, in this full-matrix form, O(m × n) space, because the whole table is retained so the edit script can be backtracked. The similarity percentage shown alongside the distance is a presentation convenience, computed as (1 − distance / max(m, n)) × 100 and defined as 100% when both strings are empty; it is not part of the formal Levenshtein definition. Every result is independently cross-checked against a second, space-optimized two-row implementation of the same recurrence, which keeps only the previous and current rows and therefore uses O(min(m, n)) space — if the two code paths ever disagreed, the badge in the tool would flag it.

Edit distance earns its keep anywhere two strings should be “the same” but were typed, transliterated, or transcribed by different people. Four uses cover most of the real demand.

• Typo tolerance and spell-checking. Rank candidate corrections by distance from the typed word and offer the closest. A threshold of 1 catches most single-key slips; 2 catches most double slips but starts returning unrelated short words.
• Record deduplication. Customer lists, supplier registers, and student rolls collect the same person under several spellings. Transliterated Sri Lankan surnames are the classic case: Perera vs Pereira is distance 1, Weerasinghe vs Weerasingha is also distance 1. Both are safely inside a d ≤ 1 merge threshold — which is exactly why a human should review the merge queue rather than trusting it blindly.
• Error-rate metrics. Character error rate is Levenshtein distance over characters divided by the reference length; word error rate is the same recurrence with whole words as the symbols. If that is what you actually need, the character error rate calculator and the word error rate calculator do the normalization for you.
• Fuzzy search and matching. Accept a query within a small distance of an indexed term instead of demanding an exact hit.

The limits are just as important. Edit distance is purely surface-level: it counts keystrokes, not meaning. Two paraphrases of the same sentence can score terribly while two unrelated short words score well, because a single edit is worth proportionally more on a short string. Nothing in the metric knows that lorry and truck refer to the same thing — they are distance 5, the maximum for words of that length. When you need semantic closeness rather than typographic closeness, an embedding-based measure such as cosine or L2 distance is the right tool; the AI text similarity checker works that way instead.

Three more caveats worth stating plainly. First, all edits cost the same, so a distance of 3 tells you how many keystrokes separate the strings but nothing about how visually or phonetically similar they are. Second, adjacent transpositions cost 2 under this metric, so form and from look further apart than a typist would judge them; Damerau–Levenshtein exists precisely to fix that. Third, the quadratic cost means comparing every pair in a large list becomes expensive fast — 10,000 records is 50 million comparisons — so production deduplication usually blocks records by a cheap key first and only then runs edit distance inside each block. For line-by-line comparison of longer documents, a diff is the better shape of answer: the text diff checker shows the changed lines directly rather than reducing everything to a single number.

• Levenshtein, V. I. (1966) — Binary codes capable of correcting deletions, insertions and reversals (Soviet Physics Doklady)
• Wagner, R. A. & Fischer, M. J. (1974) — The String-to-String Correction Problem (Journal of the ACM)
• NIST Dictionary of Algorithms and Data Structures — Levenshtein distance

The algorithm, recurrence, and worked examples on this page were last cross-checked against these sources on 2026-08-18. The distance is deterministic and verified against an independent second implementation on every calculation.