fast-levenshtein: edit distance in JavaScript with a collator option

A thin wrapper over fastest-levenshtein

The package is a JavaScript implementation of the Levenshtein algorithm, and the interesting part is what it does not implement. It uses the fastest-levenshtein library under the hood, and the dependency list in the package metadata confirms it, with fastest-levenshtein at 1.0.7 or newer as the single runtime dependency. That means the algorithm itself, the part that is easy to get subtly wrong with the wrong base case or the wrong loop bounds, is not maintained here. What this repository adds is packaging, a documented API and one feature the underlying library does not have. The feature list is short by design. It works in node.js and in the browser, it supports locale-sensitive string comparisons if needed, and it has a broad test suite. The performance section of the project documentation is a single sentence pointing back at fastest-levenshtein, which is an honest way of saying that the speed comes from the dependency rather than from any optimisation in this code.

One function with an options object

The public surface is a single call, levenshtein.get, taking two strings and returning the number of edits between them. The default usage reads like this:

var levenshtein = require('fast-levenshtein');

var distance = levenshtein.get('back', 'book');   // 2

The example covers the obvious case, two strings that differ by two substitutions. The package is CommonJS in the published form, with the entry point at levenshtein.js and the files array listing only that one file, so a project using ES modules pulls it in with a default import rather than a named one. There is no class to instantiate, no configuration object to pass and no separate distance or similarity function. The whole API is the get call, and the third argument, the options object, is where the only optional behaviour lives. The repository ships both levenshtein.js and a minified levenshtein.min.js at the top level, and the browser build is also served through the unpkg CDN, which is the path to use when you are loading the script from a page rather than from a bundler.

useCollator changes what counts as a difference

The one feature that distinguishes this package from a bare edit distance call is the collator option. The documentation describes it as supporting Intl.Collator for locale-sensitive string comparisons:

var levenshtein = require('fast-levenshtein');

levenshtein.get('mikailovitch', 'Mikhaïlovitch', { useCollator: true});
// 1

The example makes the point precisely. Without a collator, the difference between the diaeresis-free and diaeresis-bearing spelling of a name is two edits, two substitutions, one for the differing first letter and one for the accented vowel. With useCollator set to true, the comparison goes through the platform collator, which knows that those characters are related by collation rules, and the distance drops to one. Case folding is handled the same way, so a name typed in a different case is not treated as several substitutions. This matters in practice for anything that compares user-entered names, product titles or search terms, where the strings arrive from a keyboard rather than from a database that already normalised them. The cost is that the comparison is now locale dependent, which means the result of a given call can differ between environments with different locale data, and that is worth remembering if you store distances or thresholds.

A Grunt build with an old toolchain

The build and test setup is old-fashioned and worth understanding before you contribute. The instructions are to install grunt-cli globally, install the project dependencies, and run the build:

$ npm install -g grunt-cli
$ npm install
$ npm run build

The package metadata shows the vintage. The Grunt toolchain is pinned at roughly version 0.4 for grunt itself, with grunt-contrib-uglify for minification, grunt-contrib-jshint for linting, grunt-mocha-test for the test task and grunt-benchmark for the performance task. The test runner is Mocha at 11.8 or newer with chai at 1.5, and the .mocharc.yml file at the repository root carries the Mocha configuration. The four scripts in the metadata are build, prepublish, benchmark and test, and the prepublish hook runs the build so the published file is always regenerated. A contributor is asked to update or add tests for any change and to make sure the grunt build passes, with further detail in CONTRIBUTING.md. The practical note is that this is a CommonJS package with a single shipped file and a build step, so it drops into an older toolchain without ceremony, but a modern bundler setup will not need any of it.

MIT licensed, one runtime dependency, no tagged releases

The licence is MIT, with the text in LICENSE.md at the repository root, so the package can be used inside proprietary applications without a notice obligation beyond keeping the licence file. The dependency surface is the strongest argument for it. A single runtime dependency, the fastest-levenshtein package, means there is no tree of transitive packages to audit, which matters for a utility that ends up in a browser bundle or a server that is otherwise carefully kept small. The repository also keeps a benchmark directory and wires a benchmark script through grunt-benchmark, so the performance claim is at least reproducible in principle rather than asserted. On the maintenance side the picture is thin. There are no GitHub releases, so nothing is tagged and there is no changelog to read, the version in the package metadata is 3.0.0, the default branch is master, and the last push was on 2026-09-30 with the repository not archived. The CI workflow badge at the top of the README indicates that tests run on push, but a package with no tags is one you should pin by version and watch rather than track a branch.

Editorial conclusion

Adopt fast-levenshtein when you need edit distance in JavaScript and want a single dependency instead of writing the matrix yourself, and enable useCollator when your strings contain accented characters. Do not add it for a one-off comparison in a script that already has a string library, and note that the published package ships a single CommonJS file, so an ESM project needs a default import.

Frequently asked questions

Official sources

1. hiddentao/fast-levenshtein on GitHub
2. Issues
3. License: MIT
4. README