markdown-it v15 parses CommonMark in Node.js and browsers
markdown-it v15 turns Markdown into HTML through one constructor and a render call. It runs in Node.js and ships browser builds, with CommonJS and ES module exports described in the package manifest. The default preset follows the project's chosen CommonMark-compatible behavior; a separate commonmark preset aims at strict specification output, and a zero preset starts with rules disabled.
The token stream is the more important feature for tool builders. Rules are grouped into block, inline, and core stages, followed by rendering. A plugin can add syntax, change token handling, or override output without forking about 9,158 lines of source. Parsing remains synchronous, according to the architecture documentation. That suits editors and static builds, but a plugin cannot pause mid-parse for a database or network response. Resolve external data before rendering or process the tokens afterward.
A 178 MB development install is larger than the parser looks
Our sandbox installed 402 npm packages in 20 seconds and used 178 MB on disk. The source build finished in 13 seconds. That footprint includes the repository's linting, type checking, documentation, coverage, bundling, and test tools; it should not be read as the payload of every production application. The package manifest lists a narrower runtime set, while distributed builds cover server and browser consumers. Teams should inspect their bundled output because plugins and syntax highlighting can outweigh the parser.
What happened when we ran it
Our run used commit 3c51991 in an unprivileged Node 22 container with 3 CPUs, 8 GB of RAM, and no secrets. Installation succeeded in 20 seconds, adding 402 packages and using 178 MB. The build succeeded in 13 seconds. The checkout contained 162 files, about 9,158 source lines, and occupied 0.9 MB before dependencies arrived. This is the rare repository where the measured setup matched the small API shown in the README.
The test step succeeded in 23 seconds. Node's test runner reported 307 passed and 0 failed out of 307. npm audit also reported 0 known vulnerabilities across critical, high, moderate, and low severity levels. Those results cover the measured checkout and installed dependency resolution, not every third-party plugin an application may add. A plugin should be audited and tested as its own code, especially when it emits HTML attributes or changes link handling.
Our measurement setup found 2 CI workflow files, a tests directory, and no Dockerfile. A Dockerfile would add little to an npm library that runs inside another application, while the visible workflows and complete passing suite are useful maintenance signals. The 23-second test result makes local verification practical during ordinary development.
Safe defaults depend on leaving raw HTML disabled
markdown-it v15 disables embedded HTML by default, and its safety guide says this output path is safe without a sanitizer. It also rejects javascript:, vbscript:, and file: links, along with most data: URLs. Applications that turn on the html option take on a different contract: the guide tells them to pass output through an external sanitizer. Markdown syntax does not neutralize arbitrary HTML by itself.
Plugins create another boundary. The safety guide warns against deriving arbitrary id or name attributes directly from user input because that can cause DOM clobbering. Header-anchor and extended-class plugins deserve a source review before use. Prefix generated identifiers, constrain accepted attributes, and add hostile-input fixtures. The core's 0 known audit findings do not say anything about an unreviewed plugin or an unsafe renderer callback.
v15 keeps the public API and breaks old integration shortcuts
The v15 migration guide says root-package imports and the public parser API remain compatible with v14. Existing third-party plugins need their own compatibility confirmation. Bundled TypeScript types replace @types/markdown-it, browser bundle paths changed, and fuzzy bare-domain links such as example.com are no longer recognized unless explicitly enabled. Direct CDN URLs and linkification tests should be checked during an upgrade.
Package-internal imports also stopped working in v15. Common parser classes are exposed as static properties on the main export, while individual rules and presets are no longer exported. A plugin that imported markdown-it/lib/... was coupled to implementation detail and now needs revision. This boundary can turn a routine major-version bump into code changes for advanced plugins.
September 2026 fixes arrived while one link bug stayed open
GitHub recorded a push on September 11, 2026, with 21,892 stars and 8 open issues and pull requests. Issue 1208 reported quadratic behavior in the optional smart-quotes rule on September 9 and closed on September 11. That response, plus a current source push, shows active maintenance. The repository has a 15.0.2 tag but GitHub's latest-release endpoint returned no formal release object, so tags and npm metadata matter more than the Releases page here.
Open issue 1058 is the clearest reason to test optional linkification. It reports that, since v13, a URL containing Markdown-escaped hyphens and fragment characters can be linked only up to the first backslash. The issue was updated on August 26, 2026 and remained open when fetched. Applications that enable linkify for pasted developer text should add that input class to regression tests instead of assuming 307 passing core tests cover every URL form.
Passing 307 tests makes markdown-it the low-drama choice
markdown-it installed in 20 seconds, built in 13 seconds, and passed all 307 tests in 23 seconds. Its extension model is useful without forcing applications into a full document-processing framework. Choose it for CommonMark rendering, token inspection, and carefully selected plugins. Decline it when parser rules must await outside services, or when an old integration depends on v14 internals and cannot absorb the v15 migration.