Edit Distance Explained: How Text Similarity Is Measured

Ask "how similar are these two strings?" and you get a shrug — similar is a feeling until you attach a number to it. The standard number is edit distance: how many single-character changes turn one string into the other. It powers spellcheckers, fuzzy searches, deduplication, and DNA comparison. The Text Similarity Checker runs the classic Levenshtein algorithm and converts its distance into a percentage, and the interesting part is what each output does and does not tell you.

What counts as one edit

The Levenshtein distance between two strings is the smallest number of operations — insert a character, delete a character, or substitute one character for another — that transforms the first into the second. Each operation costs exactly 1, and there are no smarter moves to buy. The textbook example is kitten → sitting: substitute k→s, substitute e→i, insert g. Three edits.

a: kitten
b: sitting        distance = 3

kitten  -> sitten   (substitute k with s)
sitten  -> sittin   (substitute e with i)
sittin  -> sitting  (insert g)

The algorithm finds this minimum by filling a dynamic-programming table: each cell asks whether the best path to this pair of prefixes comes from matching a character (free), or from an insert, delete, or substitute (cost 1). The implementation here keeps only two rows of that table at a time, which is why it stays fast even on long inputs.

Turning a distance into a percentage

A raw distance has no scale — is 3 edits similar or not? The tool normalizes by the length of the longer string and reports:

similarityPercent  = (1 - distance / maxLength) x 100   (2 dp)
normalizedDistance = distance / maxLength               (4 dp)

kitten vs sitting:  3 / 7 -> similarity 57.14%, distance 0.4286

Dividing by the longer length makes the percentage symmetric — swapping the two inputs changes nothing — and pins the scale at the extremes: identical strings are 100%, and two strings sharing nothing score 0%. Two empty strings are the friendly edge case: distance 0, similarity 100%, flagged identical. One empty string against cat is distance 3, similarity 0% — you would have to insert everything.

Case and whitespace are characters too

The comparison is strictly character-by-character, so anything visible to charCodeAt counts as an edit:

Hello vs hello        distance 1 -> 80%     (capital H)
hello world vs helloworld  distance 1 -> 90.91%  (one space)

That precision is a feature when case and spacing are meaningful — file names, IDs, credit entries — and a nuisance when they are not. If you want a loose comparison, normalize first: lowercase both strings and trim the whitespace before pasting them in. One edit between five-character strings (80%) is a much bigger deal than one edit between eleven-character strings (90.91%), which is why the percentage, not the raw distance, is the number to compare across pairs of different lengths.

Anagrams are far apart, and other blind spots

Edit distance measures position-by-position agreement, not meaning or reordering. Rearrange listen into silent — same letters, same meaning-adjacent feel to a human — and the distance is 4 edits out of 6, a similarity of 33.33%. Nothing about the algorithm knows these are anagrams; every letter is in the wrong place, so every letter costs. When what you care about is which words moved, a diff view is the better lens: the Line Diff vs Word Diff article covers exactly when a positional comparison beats a summary score.

Try it yourself

Type a word and its typo into the Text Similarity Checker and watch one keystroke move the percentage — then test the Hello/hello pair to see case sensitivity at work. When a low score surprises you, open the Text Diff tool to see where the strings part ways, and use the Word Diff tool for prose, where the unit of change is a word rather than a letter.