ESLint vs Biome: Which JavaScript Linter Wins in 2026?

For most teams starting a project in 2026, the short answer is: reach for Biome if you want one fast, zero-config tool that lints and formats JavaScript and TypeScript out of the box, and stick with ESLint (paired with Prettier or ESLint Stylistic) if you need the deepest rule coverage, the largest plugin ecosystem, or you're maintaining a large existing config you can't easily replace. Both tools are free and open source, and neither is going away — the real decision is about trade-offs between raw speed, rule-set maturity, and how much configuration you're willing to own.

What ESLint and Biome Actually Do

ESLint is a pluggable static analysis tool for JavaScript and JSX. It parses your code, walks the resulting syntax tree, and flags patterns that match configured rules — from likely bugs (unreachable code, unused variables) to style and best-practice conventions. Many of those issues can be auto-fixed. ESLint has always been explicitly extensible: you can write custom rules, load third-party rule plugins, use custom parsers for new syntax, and layer "shareable configs" on top of each other. That extensibility is the whole reason the project became the default linter for the JavaScript ecosystem.

Biome describes itself as a single toolchain for web projects that can "format, lint, and more in a fraction of a second." Where ESLint is a linter you typically pair with a separate formatter, Biome bundles both into one Rust binary with one configuration file (biome.json) and one CLI. It supports JavaScript, TypeScript, JSX, TSX, JSON, HTML, CSS, SCSS, GraphQL, YAML, and Markdown for formatting, and a similar language spread for linting. It requires zero configuration to get started, though it exposes extensive options once you need them.

Speed: Why Biome (and Oxlint) Feel So Much Faster

Both Biome and the newer Oxlint linter are written in Rust, which is the headline reason people switch. ESLint is written in JavaScript and runs on Node.js; every file has to be parsed, walked, and checked inside a JS runtime, which is inherently slower than a compiled native binary doing the same work. ESLint's architecture is also built for maximum flexibility — loading arbitrary JS plugins, running arbitrary custom parsers — and that flexibility has a runtime cost.

Biome's own site makes a specific, sourced claim: formatting 171,127 lines of code across 2,104 files on an Intel Core i7-1270P, Biome's formatter runs about 35x faster than Prettier. Notably, Biome does not publish an equivalent head-to-head number against ESLint's linter on its own site — its linting benchmark page talks about Biome's internal performance (for example, the new "Scanner" feature introduced in Biome v2, which enables project-aware lint rules but can slow a run from roughly 800ms to about 2 seconds on a 2,000-file project, and from roughly 1 second to about 8 seconds on a 5,000-file project when enabled).

The clearest official ESLint-speed comparison actually comes from a third Rust-based tool: Oxlint, part of the Oxc toolchain, advertises itself as "50–100x faster than ESLint" on its own homepage, with no published benchmark methodology behind that figure. Treat it as a marketing claim from the project itself rather than an independently verified number. More broadly, exact speed multipliers for Rust-based linters versus ESLint vary a lot depending on codebase size, how many plugins your ESLint config loads, caching, and hardware — so a single "Nx faster" headline from any vendor, including Biome or Oxc, should be read as directional rather than a guarantee you'll see the same ratio on your own repository.

What's consistent across sources: linting and formatting with a native Rust tool is faster than doing the same work in a Node.js process, often dramatically so on large codebases, and that gap is the single biggest driver of Biome's and Oxlint's adoption so far.

Rule Coverage and the Plugin Ecosystem

This is where ESLint still has a real structural advantage. ESLint's own rules documentation lists roughly 200 built-in rules across "Possible Problems" and "Suggestions" categories (formatting-oriented rules have been deprecated from core — more on that below). That core number understates ESLint's real footprint, though: the ecosystem around it includes typescript-eslint, eslint-plugin-react, eslint-plugin-import, eslint-plugin-jsx-a11y, framework-specific plugins for Vue, Svelte, and Astro, and thousands of smaller community plugins, each adding its own rule set. If a framework or library has any meaningful adoption, there's a decent chance someone has written an ESLint plugin for it.

Biome, by contrast, ships 670 built-in lint rules in a single package, many explicitly inspired by or ported from ESLint, typescript-eslint, and other linters' rule sets. Biome also added a JavaScript plugin system and GritQL-based custom rules in recent 2.x releases, so the extensibility gap is narrowing, but its third-party plugin ecosystem is nowhere near as deep as ESLint's yet — most of what you get is what ships in the box. Biome includes a biome migrate eslint command that ports rules from an existing ESLint config, but its own migration guide is upfront that rule parity is incomplete: some rule options aren't implemented, and some ported rules intentionally behave differently than their ESLint counterparts.

Formatting: Biome's Built-In Formatter vs ESLint + Prettier

ESLint does not format your code in the way Prettier does. Its own documentation on output formatters is explicit that "formatters" in ESLint's context means how lint results are displayed (stylish, json, html, and so on) — not code formatting. Historically, people used ESLint's stylistic rules (indent, semi, quotes, etc.) as a rough formatter, but ESLint has deprecated those rules from core and moved them to the separate ESLint Stylistic project. In practice, almost every ESLint-based project today either runs Prettier alongside ESLint (with eslint-config-prettier to disable conflicting rules) or adopts ESLint Stylistic for formatting-as-linting. Either way, that's a second tool, a second config file, and a second thing to keep in sync.

Biome's formatter is built in from day one, claims 97% compatibility with Prettier's output according to its own documentation, and runs as part of the same biome check command that also lints. For teams that found the ESLint+Prettier combination (and the config conflicts it can produce) annoying, this single-binary, single-config approach is Biome's clearest practical advantage over the ESLint stack.

Feature-by-Feature Comparison

Adoption: Who's Actually Using What

ESLint has the incumbency advantage of roughly a decade in production. Per its own site, it sees over 200 million npm downloads a week and is used by companies including Microsoft, Airbnb, Netflix, and Facebook — and the shareable-config model (Airbnb's config, for instance) is baked into how a huge number of existing codebases are set up. That installed base is exactly why ESLint isn't going anywhere soon: migrating a large, multi-team monorepo off a mature lint config is real work, independent of how fast the replacement tool is.

Biome is younger (it grew out of the earlier Rome project) but has moved quickly: it's on GitHub with roughly 26,000 stars, and recent 2.x releases have added Markdown, SCSS, and YAML support, a JavaScript plugin API, and better Tailwind CSS integration — signs of a project actively chasing feature parity with the ESLint+Prettier stack rather than staying a narrow, fast alternative. Teams building new projects, or already using fast Rust-based tooling elsewhere in their stack, are the ones most likely to have adopted it first, part of a broader trend of JavaScript tooling moving from Node.js to compiled, native binaries for speed.

Migration Path: Moving From ESLint (+ Prettier) to Biome

Biome ships dedicated commands for this: biome migrate eslint --write reads your existing ESLint config (legacy or flat), follows extends chains, loads shared and plugin configs, and migrates .eslintignore patterns into biome.json, enabling only the rules it can map with confidence. A separate flag, --include-inspired, also pulls in rules that are merely "inspired by" their ESLint equivalents rather than exact matches. biome migrate prettier --write does the equivalent for your Prettier config, writing every formatting option explicitly since Biome's defaults differ from Prettier's.

According to Biome's own migration guide, this is not a drop-in, zero-review process. Plugins or shared configs with cyclic references can make the ESLint migration fail outright, requiring you to comment them out and reintroduce them one at a time. Rule parity is explicitly described as incomplete: some rule options aren't implemented, and some migrated rules behave differently on purpose. ESLint and Prettier ignore .gitignore entries by default; Biome only does so if its VCS integration is explicitly enabled. The realistic migration path is: run the migration commands, diff the generated biome.json against your intent, run Biome against your codebase and review the delta in reported issues, then remove ESLint, Prettier, and their editor extensions once you're satisfied. For teams also weighing a package-manager switch as part of a broader tooling refresh, it's worth reading alongside our pnpm vs npm vs Yarn vs Bun comparison, since both moves are usually justified by the same underlying goal: faster local and CI feedback loops.

Where Oxlint Fits In

Oxlint, part of the Oxc project, is worth naming because it's the fastest-moving third option in this space, even though it isn't this article's main comparison. It bills itself as an "ESLint-compatible linter," claims 800+ rules, offers type-aware linting powered by a TypeScript-in-Rust project called tsgo, and says it supports ESLint JS plugins for extensibility. Oxc's broader toolchain also includes Oxfmt, a formatter in beta that the project claims is roughly 3x faster than Biome's formatter and 30x faster than Prettier — again, these are the project's own figures rather than independently audited benchmarks. Some teams are starting to run Oxlint purely for its fast first pass in CI, while keeping ESLint or Biome for rules Oxlint doesn't yet cover. It's a project to watch rather than a mature replacement for either ESLint or Biome today, but it's a sign that the "linting should be this slow" assumption is being challenged from multiple directions at once.

Which to Pick in 2026

Pick ESLint (plus Prettier or ESLint Stylistic) if: you're maintaining a large existing codebase with a mature config and plugin set you don't want to re-litigate; you depend on a specific framework plugin (say, a niche React, Vue, or accessibility plugin) that doesn't have a Biome equivalent yet; or your team's custom lint rules are written as ESLint plugins and rewriting them isn't worth it right now.

Pick Biome if: you're starting a new project and want one fast tool instead of two slower ones; your CI lint-and-format step is a noticeable bottleneck on a large codebase; or you want to standardize JS/TS/JSON/CSS formatting without debugging ESLint-vs-Prettier rule conflicts. Its migration tooling makes trying it on an existing project low-risk, since you can run it side by side with ESLint before committing to a full cutover.

Consider Oxlint as a complement, not a replacement, for now: several teams run it as an extremely fast first-pass check (catching obvious problems in milliseconds) while still relying on ESLint or Biome for full rule coverage, especially anything requiring mature TypeScript-aware or framework-specific rules.

What Next

If you're evaluating this for an existing project, the lowest-risk path is to install Biome alongside your current ESLint/Prettier setup, run biome migrate eslint and biome migrate prettier, and diff the output against your current lint results on a feature branch before touching CI. For a new project, Biome's zero-config defaults are a reasonable starting point; add ESLint plugins later only for the specific rules you find you actually need. Whichever linter you land on, pair the decision with the rest of your toolchain: see our guides to Node.js 26 vs Node.js 24 and Zed vs VS Code for how runtime and editor choices interact with your linting setup.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage