Biome vs ESLint vs Oxlint 2026: Which JavaScript Linter Actually Saves You Time?
If you’re still running ESLint on a monorepo and watching your CI lint step take four minutes, you’ve probably asked the question: is there something faster? The answer, in 2026, is yes — plural. Biome and Oxlint have both matured to the point where they’re legitimate production options, not weekend experiments. But “faster” only matters if you’re not giving up something you actually need.
This article compares all three linters head-to-head: ESLint (v10.4, the incumbent), Biome (v2.x, the Rome successor with built-in type inference), and Oxlint (the Oxc-powered upstart backed by VoidZero). I’ve run the benchmarks, dug through the config systems, tested the editor integrations, and migrated real projects to figure out where each tool shines and where each one falls short.
If you want a quick answer, skip to the Quick Verdict. If you need the full picture before committing your team’s toolchain, read on.
Quick Verdict
Use Biome if you want the best balance of speed, features, and ecosystem independence. It’s fast enough (25–35× ESLint), ships a formatter, handles type-aware rules without the TypeScript compiler, and its configuration is genuinely simple. For most small-to-mid-size projects, Biome is the sweet spot in 2026.
Use Oxlint if raw speed is your top priority and you’re working in a large monorepo where lint time is a real bottleneck. At 50–100× ESLint’s speed, it’s in a different performance class. The type-aware linting via tsgo (the Go port of the TypeScript compiler) is technically superior. For queue-based background job processing in your development pipeline, check out our top 5 background job queues for indie SaaS. But it’s still earlier in its maturity arc — fewer editor integrations, no built-in formatter, and the plugin system is still evolving.
Stick with ESLint if your project depends on niche plugins that Biome and Oxlint haven’t ported yet, or if your team doesn’t have bandwidth for a migration right now. ESLint v10 is solid, the ecosystem is unmatched, and “it works” is a legitimate reason to stay put.
The Contenders: A Brief Introduction
ESLint — The Incumbent
ESLint has been the default JavaScript linter for nearly a decade. Version 10.4 (released May 2026) continues the flat-config era with incremental improvements — the new includeIgnoreFile() helper, better sequence expression handling, and the usual bug fixes. ESLint’s architecture is Node.js-based and single-threaded, which means it processes files one at a time. For large codebases, that’s a structural bottleneck no amount of configuration can fix.
What ESLint still has going for it: 20,000+ community plugins, native support in every editor and CI platform, and a configuration system that — while sometimes confusing — can express almost any rule composition you can imagine.
Biome — The All-in-One Challenger
Biome started as a fork of Rome and has carved out its own identity as the “fast, opinionated, batteries-included” toolchain. Version 2.0 (released June 2025, codenamed “Biotype”) was a watershed — it introduced type-aware linting using Biome’s own type inference engine, not the TypeScript compiler. That means you can get type-based checks like noFloatingPromises without installing typescript at all.
Biome also ships a Prettier-compatible formatter (97% compatibility), multi-file analysis, and a single biome.json config that covers linting and formatting. It’s written in Rust and runs parallelized by default.
Oxlint — The Speed Demon
Oxlint is part of the Oxc (Oxidation Compiler) project, backed by VoidZero — the same organization behind Rolldown (Vite’s bundler). Written in Rust, Oxlint’s architecture is purpose-built for maximum throughput: parallelized parsing, shared AST across rules, and zero startup overhead.
In 2026, Oxlint added two significant capabilities: type-aware linting via tsgo (the Go port of the TypeScript compiler, aka TypeScript 7), and multi-file analysis as a first-class feature. It also supports JS plugins compatible with the ESLint plugin ecosystem, lowering the migration barrier. With 787 rules and a built-in ESLint config migration tool, Oxlint is clearly aiming to be a drop-in ESLint replacement for large teams.
Head-to-Head Comparison
1. Performance: Raw Speed
Let’s start with the number everyone asks about first.
| Benchmark | ESLint | Biome | Oxlint |
|---|---|---|---|
| Lint 171K lines (2,104 files) | ~12s (baseline) | ~0.4s (30×) | ~0.15s (80×) |
| Cold start + lint (1K files) | ~3.2s | ~0.15s | ~0.08s |
| Incremental (100 changed files) | ~1.8s | ~0.05s | ~0.02s |
Numbers are approximate, based on public benchmarks and my own testing on an Intel i7-1270P. Your numbers will vary by project size, rule count, and hardware.
The picture is clear: both Biome and Oxlint obliterate ESLint on throughput. Oxlint is roughly 2–3× faster than Biome, which is itself 25–35× faster than ESLint. For a 500-file project, the difference between 0.08s and 0.4s is perceptually zero. For a 50,000-file monorepo, the difference between 1.5s and 6s starts to matter — and ESLint’s 40+ seconds is just painful.
But raw speed isn’t the whole story. Biome’s type-aware mode (with the file scanner enabled) is slower than its single-file mode — early beta reports noted a 3–5× slowdown for full-project scans. Oxlint’s type-aware mode, powered by tsgo, adds overhead too, though the architecture shares parsed results across rules to minimize redundant work.
Takeaway: If you’re linting fewer than 10K files, Biome and Oxlint both feel instant. For massive repos, Oxlint has a meaningful edge. ESLint is the only one where you’ll reach for a coffee while waiting.
2. Rule Coverage and Quality
Speed without rules is just a fast no-op. Here’s how the rule counts stack up:
| ESLint v10 | Biome v2 | Oxlint | |
|---|---|---|---|
| Core/built-in rules | ~90 core | 502 | 787 |
| Community plugins available | 20,000+ | Growing (JS plugins) | JS plugin compat + ESLint bridge |
| Rules on by default | Varies by config | Recommended set | 111 (correctness-focused) |
| Auto-fixable rules | Many (varies by plugin) | Majority | 293 |
ESLint’s 20,000+ plugins represent its greatest strength and its biggest liability. The plugin ecosystem means you can find a rule for almost anything — React, Vue, Jest, accessibility, security, framework-specific patterns. But it also means inconsistent quality, abandoned packages, and configuration hell when three plugins disagree about the same code pattern.
Biome’s 502 rules are all first-party, which means consistent diagnostic quality, uniform configuration, and no dependency on external maintainers. The coverage spans correctness, style, complexity, security, and TypeScript-specific patterns. Biome deliberately avoids porting “stylistic” rules that its formatter handles instead — a design choice that keeps the lint/format boundary clean.
Oxlint’s 787 rules cover a wider 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. This is a deliberate design: Oxlint wants to be useful out of the box without drowning you in warnings.
Type-aware linting is where the 2026 landscape gets interesting:
- ESLint + typescript-eslint: The gold standard for type-aware rules, but requires running the TypeScript compiler, which is slow. In CI, this can add 30–60 seconds for large projects.
- Biome v2: Custom type inference engine. Doesn’t need the TypeScript compiler. Currently detects ~75% of the floating promises that typescript-eslint catches, per Biome’s own testing. Coverage is improving but not yet at parity.
- Oxlint + tsgo: Uses the native Go port of the TypeScript compiler, providing full TypeScript compatibility and the same type system behavior as tsc itself. In theory, this is the best of both worlds — type-aware accuracy at near-native speed.
Takeaway: For pure rule count and ecosystem breadth, ESLint wins. For curated, high-signal rules that don’t need external plugins, Biome is strong. Oxlint has the most rules and the technically superior type-aware approach, but some of those 787 rules are newer and less battle-tested than Biome’s or ESLint’s equivalents.
3. Configuration Experience
Configuration is where tooling opinions become tooling pain.
ESLint (flat config, v9+): The new flat config system is a genuine improvement over .eslintrc — it’s just JavaScript, no JSON/YAML parsing surprises. But composing 8 plugin configs with override hierarchies still produces files that are 150+ lines and require tribal knowledge to modify. The includeIgnoreFile() helper in v10.4 is a nice touch, but it doesn’t solve the core complexity.
Biome: One biome.json file covers linting and formatting. No plugin composition. No extends chains. You enable rule groups or individual rules, set severity levels, and you’re done. A typical Biome config is 30–50 lines. The v2 migration command (npx @biomejs/biome migrate --write) handles breaking changes automatically.
Oxlint: Configuration via oxlintrc.json. It’s simpler than ESLint’s flat config but less documented than Biome’s. The ESLint config migration tool is a killer feature — point it at your eslint.config.js and it generates an equivalent Oxlint config. Not perfect for every edge case, but it handles the common patterns.
Takeaway: Biome wins on configuration simplicity by a wide margin. One file, one schema, no plugin ecosystem to navigate. Oxlint’s migration tool makes switching easier. ESLint’s config is powerful but complex — and the complexity scales with the number of plugins you use.
4. IDE Integration
A linter you only run in CI is a linter your developers will ignore. Editor support matters.
ESLint: First-class support everywhere. VS Code, WebStorm, Neovim, Sublime — every editor with JS support has an ESLint extension. The VS Code extension is maintained by the ESLint team itself. Auto-fix on save works reliably. This is ESLint’s unshakeable moat.
Biome: Official VS Code extension (first-party), plus community extensions for other editors. Biome’s VS Code extension provides lint + format on the fly, with auto-fix suggestions. Support for Zed, Neovim, and other editors is available through the Biome LSP server. It’s good, but the ecosystem isn’t as deep as ESLint’s — you may hit edge cases with less common editors.
Oxlint: Editor support is the weakest of the three. There’s a VS Code extension, but it’s newer and less polished than Biome’s or ESLint’s. The LSP server exists but is still maturing. If your team uses WebStorm or a less common editor, Oxlint’s integration story is incomplete. This is the area most likely to improve in the next 6–12 months.
Takeaway: ESLint is the only option with universal, battle-tested editor support. Biome is good for VS Code users and adequate elsewhere. Oxlint is fine for CI-first workflows but may frustrate developers who expect real-time linting in their editor.
5. Ecosystem and Community
ESLint: The ecosystem is the product. NPM has thousands of ESLint plugins. Every major framework (React, Vue, Angular, Svelte, Next.js, Nuxt) has official or de facto standard ESLint configs. Stack Overflow answers, blog posts, and StackOverflow threads for ESLint outnumber Biome and Oxlint combined by 100×. If you hit a problem with ESLint, someone has already solved it.
Biome: Growing fast. The v2 release generated significant buzz, and the type inference feature attracted users who were tired of typescript-eslint’s overhead. Biome has an active Discord, regular releases, and corporate sponsorship (including Vercel for the type inference work). But the plugin ecosystem is still nascent — you can’t yet find a Biome plugin for every niche framework.
Oxlint: Backed by VoidZero (Evan You’s company), which gives it serious institutional backing and a clear role in the Vite/Rolldown toolchain. High-profile adopters include Preact, Shopify, ByteDance, and Shopee. The JS plugin system (compatible with ESLint plugins) is a smart bridge strategy. But the community is smaller, documentation is thinner, and the “Oxc ecosystem” is still coalescing.
Takeaway: ESLint’s ecosystem is its greatest moat. No one gets fired for choosing ESLint. Biome’s ecosystem is functional for mainstream projects. Oxlint’s institutional backing is strong, but the grass-roots community is still growing.
6. Migration Difficulty
Talk is cheap. Let’s talk about how much it actually hurts to switch.
ESLint → Biome: Moderate effort. Biome provides an init command and a migrate command. The main work is mapping your ESLint rule config to Biome’s rule names (they’re different), deciding what to do with plugins Biome doesn’t have equivalents for, and adjusting your CI scripts. For a typical React project with 5–8 ESLint plugins, expect 1–2 days of migration work. Some rules won’t have direct equivalents — you’ll either drop them, accept Biome’s alternative, or run ESLint alongside Biome for those specific rules.
ESLint → Oxlint: Easier than you’d expect, thanks to the migration tool. Oxlint’s 787 rules cover most of the common ESLint plugin rules, so the mapping is more direct. The JS plugin compatibility layer means you can theoretically keep using ESLint plugins that Oxlint hasn’t natively ported. In practice, expect some rough edges with less common plugins. Budget 1–3 days depending on your config complexity.
Biome → Oxlint or vice versa: Less common, but not unheard of. The configs are different enough that you’re essentially starting fresh, though both tools share the “minimal config, opinionated defaults” philosophy so the conceptual mapping is straightforward.
The “run two linters” strategy: A legitimate approach for large projects. Run Oxlint or Biome for the 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, at the cost of maintaining two lint configs.
Takeaway: Both Biome and Oxlint have invested in making ESLint migration as painless as possible. Oxlint has the edge on tooling (migration tool + JS plugin compat), but Biome’s simpler config means there’s less to migrate in the first place. Neither migration is trivial for a complex project, but neither is a multi-week ordeal either.
Who Should Use What?
Who Should Use Biome
- Teams that want one tool for both linting and formatting
- Projects that don’t depend on niche ESLint plugins
- Developers who value configuration simplicity over maximum flexibility
- Teams adopting type-aware linting who want it without the tsc overhead
- New projects where you can start with Biome from day one
Who Should Use Oxlint
- Large monorepos (50K+ files) where lint time is a measurable CI cost
- Teams that want the fastest possible feedback loop
- Projects invested in the Vite/VoidZero ecosystem (Rolldown, etc.)
- Teams that need type-aware rules with full tsc parity via tsgo
- Organizations that can tolerate less mature editor integration
Who Should Stick with ESLint
- Projects using uncommon ESLint plugins with no Biome/Oxlint equivalent
- Teams without bandwidth for a migration right now
- Organizations where “industry standard” matters for hiring and onboarding
- Projects where the lint step is fast enough that speed isn’t a pain point
- Teams that need maximum editor support across heterogeneous IDE setups
Who Should Avoid Each Tool
- Avoid Biome if you depend on a specific ESLint plugin that has no Biome equivalent and no viable alternative. Don’t underestimate this — some teams have 15+ ESLint plugins, and the long tail of niche rules matters to them.
- Avoid Oxlint if your team relies heavily on real-time editor linting and uses something other than VS Code. The IDE story isn’t there yet.
- Avoid ESLint if your CI lint step is longer than 30 seconds and you’re unwilling to invest in the workaround complexity (caching, incremental runs, parallel processes) that ESLint requires to be fast.
Is It Worth Switching from ESLint?
This is the question that actually matters, and the honest answer is: it depends on your pain level.
If your ESLint setup runs in under 10 seconds in CI, switching tools is a nice-to-have, not a need-to-have. The migration cost is real, and the benefit is marginal for small projects. Stay with ESLint, maybe slim down your plugin list, and call it done.
If your ESLint step takes 30+ seconds — or, heaven forbid, minutes — switching to Biome or Oxlint will meaningfully improve your development cycle. The time savings compound: faster CI means faster merges, faster deploys, and less context-switching while you wait for the pipeline.
If you’re starting 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.
The strategic consideration: Oxlint’s backing by VoidZero and integration with the Vite/Rolldown toolchain gives it a long-term trajectory that’s hard to ignore. If Vite continues to dominate the build-tool landscape, Oxlint’s position strengthens. But Biome’s independence is also a feature — it’s not tied to any single framework’s roadmap.
Free vs Paid: Pricing Comparison
All three tools are free and open source:
- ESLint: MIT license. Fully open source. No paid tiers.
- Biome: MIT license (or Apache 2.0, depending on the component). Fully open source. No paid tiers. Sponsorship via Open Collective.
- Oxlint: MIT license. Fully open source. No paid tiers. Backed by VoidZero (commercial entity), but the tool itself is free.
There are no feature gates, no “enterprise” tiers, no usage limits. The cost is only in migration effort and learning curve, not in license fees.
Alternatives Worth Knowing About
- deno lint: Good if you’re already in the Deno ecosystem. Limited rule set compared to the big three, and the Deno-specific conventions don’t translate well to Node.js projects.
- StandardJS: The original “no config” linter. Still works, but its rule set is tiny and it hasn’t kept up with modern TypeScript patterns. More of a philosophical statement than a practical tool in 2026.
- TypeScript’s built-in checks: Not technically a linter, but
tsc --noEmitcatches many correctness issues. The overlap with type-aware lint rules is significant. If you’re running tsc anyway, you may not need all the type-aware rules from your linter. - Rome (original): Archived. Don’t use it. Biome is the successor.
Final Recommendation
For most teams in 2026, here’s my decision tree:
- New project? Start with Biome. You get lint + format in one tool, simple config, good speed, and type-aware rules without the TypeScript compiler. It’s the path of least resistance that doesn’t sacrifice capability.
- Existing project with modest ESLint setup? Migrate to Biome when you next have a sprint with tooling capacity. The migration is straightforward, and you’ll simplify your toolchain permanently.
- Large monorepo where lint speed is a bottleneck? Evaluate Oxlint first. The speed difference is real and measurable. If your editor integration needs are modest (VS Code + CI), Oxlint is ready for production. If not, run Oxlint in CI and Biome or ESLint locally.
- Deeply invested in specific ESLint plugins? Stay with ESLint for now. Track Biome and Oxlint’s plugin coverage — it’s improving fast. Re-evaluate in 6 months.
None of these tools is a bad choice. The JavaScript linting landscape in 2026 is genuinely competitive for the first time in years, and that competition is making all three tools better. The worst decision is no decision — if ESLint is slow and you keep complaining about it but never switch, that’s the real waste.
FAQ
Can I run Biome or Oxlint alongside ESLint?
Yes, and many teams do exactly this during migration. Run the fast linter (Biome or Oxlint) for common checks and ESLint for the rules that don’t have equivalents yet. Just make sure you don’t have conflicting rules between the two — disable overlapping rules in one tool or the other. The “dual linter” setup is a pragmatic intermediate step, not a permanent goal.
Does Oxlint support all ESLint plugins?
Oxlint supports JS plugins that are compatible with the ESLint plugin API, and it has native ports of the most popular ESLint plugin rules (React, TypeScript, Jest, Import, Unicorn, jsx-a11y). It doesn’t support all ESLint plugins natively — only the ones that have been ported. The JS plugin compatibility layer helps bridge the gap for rules that haven’t been ported yet, but you may hit edge cases with complex plugins that rely on ESLint internals.
How does Biome’s type inference compare to typescript-eslint?
Biome’s own testing shows their type inference catches roughly 75% of the floating promises that typescript-eslint would catch. This is a meaningful gap, not a rounding error. Biome’s approach is faster (no tsc dependency) and improving rapidly, but if you need maximum type-aware correctness, typescript-eslint (or Oxlint with tsgo) is still more thorough. For most projects, 75% coverage of the trickiest rules is enough to catch the common mistakes.
Is Oxlint’s type-aware linting using tsgo production-ready?
As of mid-2026, Oxlint’s type-aware mode via tsgo is available and functional, but it’s still relatively new. tsgo (the Go port of the TypeScript compiler, sometimes called “TypeScript 7”) is an official Microsoft project, which gives it credibility, but Oxlint’s integration layer is still maturing. I’d recommend thorough testing on your codebase before relying on it for critical type checks in CI. The architecture is sound; the implementation needs more battle-testing.
Which linter has the best auto-fix capabilities?
ESLint has the most auto-fixes overall, simply because every plugin can define its own fixes. Biome’s auto-fix is reliable and consistent across all 502 rules — the fixes are safe and don’t produce broken code in my experience. Oxlint has 293 auto-fixable rules with clear safety indicators (safe fix vs. dangerous fix vs. suggestion). In practice, Biome’s fixes feel the most predictable because they’re all first-party. ESLint’s fixes vary wildly in quality depending on the plugin author.
Related Articles
- Drizzle vs Prisma vs Kysely 2026: Best TypeScript ORM — More JavaScript toolchain comparisons if you liked the Biome vs ESLint breakdown.
- Bun 1.2 vs Deno 2 vs Node.js 22 2026: JavaScript Runtime Showdown — The JavaScript ecosystem keeps evolving; here’s how the runtimes compare.
- Turbopack vs Vite vs esbuild 2026: Fastest JavaScript Bundler — Speed comparisons across the JS build tool landscape.
Quick Comparison Table
| Feature | Biome | ESLint | Oxlint |
|---|---|---|---|
| Performance | 10x faster than ESLint | Baseline | 20x faster than ESLint |
| TypeScript Support | Native | Plugin required | Partial |
| Plugin Ecosystem | Limited | 15,000+ plugins | 85% compatible |
| Config Complexity | Simple (biome.json) | Complex (.eslintrc) | ESLint-like |
| Best For | New projects | Enterprise | Migration path |