Biome vs ESLint vs Oxlint (2026): Which JavaScript Linter Actually Saves You Time?

Originally posted on PikVue — full benchmark methodology and extended rule coverage analysis available there.

If your CI lint step takes four minutes on a monorepo, you've probably wondered: is there something faster? The answer in 2026 is a resounding yes — but you need to know what you're trading off.

I tested ESLint v10.4, Biome v2, and Oxlint head-to-head on real projects. Here's what I found.

Quick Verdict

Use Biome if you want the best balance of speed, features, and simplicity — it's 25-35× faster than ESLint, ships a formatter, and handles type-aware rules without the TypeScript compiler.

Use Oxlint if raw speed is your top priority and you're in a large monorepo where lint time is a real bottleneck. At 50-100× ESLint's speed, it's in a different performance class — but it's earlier in its maturity arc.

Stick with ESLint if your project depends on niche plugins that Biome and Oxlint haven't ported yet. "It works" is a legitimate reason to stay put.

Performance: The Numbers Everyone Asks For

Benchmark	ESLint	Biome	Oxlint
171K lines (2,104 files)	~12s	~0.4s (30×)	~0.15s (80×)
Cold start + 1K files	~3.2s	~0.15s	~0.08s
Incremental (100 files)	~1.8s	~0.05s	~0.02s

Both Biome and Oxlint obliterate ESLint on throughput. For a 500-file project, the difference between 0.08s and 0.4s is imperceptible. For a 50,000-file monorepo, the gap between 1.5s and 6s (and ESLint's 40+ seconds) starts to matter a lot.

Rule Coverage and Quality

ESLint's 20,000+ plugins are both its greatest strength and biggest liability. You can find a rule for almost anything — but you also get inconsistent quality, abandoned packages, and configuration hell.

Biome's 502 rules are all first-party, meaning consistent diagnostic quality and uniform configuration. It deliberately avoids "stylistic" rules that its formatter handles instead — keeping the lint/format boundary clean.

Oxlint's 787 rules cover the widest surface area, including ports of popular ESLint plugin rules (React, Jest, Vitest, Import, Unicorn, jsx-a11y, TypeScript). The 111 default-on rules are correctness-focused — they surface genuinely broken code, not style preferences.

Type-aware linting is where things get interesting in 2026:

• ESLint + typescript-eslint: The gold standard, but requires running tsc which is slow (30-60s for large projects).
• Biome v2: Custom type inference engine. ~75% of floating promises detection vs. typescript-eslint. No tsc dependency.
• Oxlint + tsgo: Uses the Go port of the TypeScript compiler (Microsoft's official TypeScript 7). Full type accuracy at near-native speed.

Configuration Experience

Biome wins here by a wide margin. One biome.json file covers linting and formatting. No plugin composition. No extends chains. A typical config is 30-50 lines.

ESLint's flat config is a genuine improvement over .eslintrc, but composing 8 plugin configs with override hierarchies still produces 150+ line files that require tribal knowledge.

Oxlint's config via oxlintrc.json is simpler than ESLint but less documented than Biome. The ESLint config migration tool is a killer feature — point it at your eslint.config.js and it generates an equivalent Oxlint config.

Is It Worth Switching?

The honest answer: it depends on your pain level. If your ESLint setup runs in under 10 seconds in CI, switching is a nice-to-have, not a need-to-have. If your lint step takes 30+ seconds — or minutes — switching to Biome or Oxlint will meaningfully improve your development cycle. Faster CI means faster merges, faster deploys, and less context-switching.

For a new project in 2026, there's almost no reason to start with ESLint unless you know you'll need a specific plugin. Biome gets you to 90% of what ESLint provides with 10% of the configuration effort. Oxlint gets you there with even more speed, at the cost of some editor convenience.

Migration difficulty

Both Biome and Oxlint have invested in making ESLint migration painless. Biome provides init and migrate commands. For a typical React project with 5-8 ESLint plugins, expect 1-2 days of migration work. Oxlint's ESLint config migration tool is a killer feature — point it at your eslint.config.js and it generates an equivalent Oxlint config. The JS plugin compatibility layer means you can keep using ESLint plugins that haven't been natively ported.

A legitimate strategy for large projects: run Oxlint or Biome for fast, common checks and keep ESLint for the long tail of plugin rules. This gives you speed where it matters and coverage where you need it.

The Bottom Line

Scenario	Recommendation
New project?	Start with Biome. Lint + format in one tool, simple config, excellent speed.
Modest ESLint setup?	Migrate to Biome when you have tooling capacity.
Large monorepo, lint speed is a bottleneck?	Evaluate Oxlint first. The speed difference is real.
Deeply invested in niche ESLint plugins?	Stay with ESLint for now. Track Biome and Oxlint's plugin coverage.
Can't decide?	Run a dual linter setup — fast linter in CI, ESLint for the long tail.

For the complete rule coverage tables, editor integration comparison, and migration strategy guide, check out the full article on PikVue.

About the author: This article was originally published on PikVue, a tech review site that runs real-world benchmarks on developer tools. No sponsored content — just honest, data-driven comparisons from developers who actually use these tools daily.