If your lint checks are slow or your tooling feels fragmented, the best replacement depends on which rules and formatting work you need to keep. ESLint offers mature flexibility, Biome joins linting and formatting, and Oxlint focuses on fast linting. Type-aware linting means lint rules use project type information to catch issues that ordinary syntax checks cannot determine. Your choice rests chiefly on existing rules, formatting needs, and whether linting slows your developer workflow. A code quality decision can affect local edits as well as slow CI, so switching tools means more than chasing a shorter run. Treat the comparison as a way to identify the smallest toolchain that still covers your project’s real requirements.
Key Takeaways
- Biome is a practical start when you want one tool for formatting and linting.
- ESLint fits projects that depend on specialist plugins or custom rules.
- Oxlint suits teams that need faster lint feedback.
- Rule coverage matters more than a tool’s headline rule count.
- Compare candidate tools on the same codebase before removing current checks.
ESLint vs Biome vs Oxlint 2026: Which Tool Fits Your Project?
For a new project that wants one formatter and linter, start by evaluating Biome; keep ESLint for essential specialist rules and consider Oxlint when lint time is the bottleneck. Start with the job your project needs most, then check whether the other tools cover the rest.
The State of JS 2025 utility survey reports usage of ESLint at 90%, Biome at 16%, and Oxlint at 1%. Those shares describe adoption, not which tool will suit your repository. Your rules, files, and workflow should drive the choice.
| Tool | Best fit | Main tradeoff |
|---|---|---|
| ESLint | Projects that need specialist plugins | Often needs a separate formatter |
| Biome | Teams that want linting and formatting together | Does not cover every ESLint plugin |
| Oxlint | Projects where lint speed is the main concern | Does not provide Biome’s formatter |
Choose by the work your current setup must still do, not by a speed ranking alone.
When a unified formatter and linter matter most
Biome makes sense when your team wants one package to handle everyday linting and code style. That choice can reduce the number of tools and settings you maintain. It is a useful ESLint alternative when you value a shared formatter more than a broad plugin ecosystem.
Biome vs ESLint in 2026 comes down to the formatter-versus-ecosystem distinction. Biome combines formatting and linting, while ESLint remains a stronger fit when a project depends on specialist rules. A team can still keep both when their jobs are clearly split.
When plugin coverage or raw lint speed matters more
Oxlint vs Biome vs ESLint is also a lint-only-versus-all-in-one choice. Oxlint is a linter focused on speed; Biome pairs a linter with a formatter; ESLint brings broad plugin choices. If you are weighing ESLint alternatives, choose Biome for unified formatting or Oxlint for fast linting.
A tool that fits a small app may not fit a mature codebase with internal rules. Write down the checks your team relies on, including checks beyond JavaScript. That list makes tradeoffs concrete before you change a command.
What Does Each Tool Actually Do?
These tools overlap on linting, but they are not interchangeable toolchains. Each has a different center: ESLint emphasizes plugins, Biome combines several code tasks, and Oxlint focuses on linting.
A faster linter does not automatically replace every task your existing setup performs. Formatting, import sorting, and specialist checks may belong to separate tools. List those jobs before comparing runtimes.
ESLint checks code through configurable rules and plugins
ESLint is a pluggable JavaScript linter. You choose rules, add plugins, and set configuration for the files in your project. That system lets teams shape checks around frameworks, tests, and local conventions.
Its wide configuration system can handle a setup that has grown over years. The same flexibility can also mean more dependencies and more settings to understand. ESLint checks code; a separate package such as Prettier often handles formatting.
Biome combines linting and formatting in one toolchain
Biome brings linting, formatting, and import sorting into one package. A central config file sets how those tasks should run. That can make a smaller system easier to explain to new team members.
Its combined approach does not mean every ESLint rule or plugin has a direct match. A project may use Biome for common checks and another tool for a few special cases. The right setup depends on what your codebase actually needs.
Oxlint focuses on fast JavaScript and TypeScript linting
Oxlint is the linter in the OXC toolchain. It aims to check JavaScript and TypeScript code quickly, with many rules built in. It does not take over formatting in the same way Biome does.
Teams can pair Oxlint with a formatter or continue using ESLint for checks it does not cover. That split can reduce lint time while preserving needed rules. Before comparing runtimes, list the separate jobs your current setup performs.
How Fast Are ESLint, Biome, and Oxlint in Benchmarks?
The measured results show a consistent advantage for Oxlint in these benchmark cases, but the size of the gap changes by workload. One test is not a promise for every repository or machine.
Run times depend on file count, enabled rules, type-aware checks, and the benchmark setup. Use these numbers to understand scale, then compare the tools with your own files and settings.
| Comparison | Runtime A | Runtime B | Reported speed difference |
|---|---|---|---|
| Oxlint versus Biome | Oxlint: 138.6 ms | Biome: 377.2 ms | Oxlint 2.72 ± 0.06 times faster |
| Oxlint versus ESLint, VS Code benchmark 1 | Oxlint: 499.6 ms | ESLint: 31.025 s | Oxlint 62.10 ± 1.86 times faster |
| Oxlint versus ESLint, VS Code benchmark 2 | Oxlint: 177.2 ms | ESLint: 20.957 s | Oxlint 118.25 ± 6.78 times faster |
| Biome formatter versus Prettier | Biome: runtime not stated | Prettier: runtime not stated | Roughly 25x faster |
The first comparison puts Oxlint at 138.6 milliseconds and Biome at 377.2 milliseconds. The two VS Code tests show larger gaps against ESLint, though their results reflect their own workloads. A different file set or rule mix can change the result.
Biome’s published figures put its formatter at roughly 25 times the speed of Prettier and its linter at around 20 times the speed of ESLint. Those figures offer a broad comparison, not a guarantee for your project. Biome’s published benchmark figures describe those measured comparisons.
A benchmark also depends on how each tool starts, which files it reads, and what checks it runs. Compare the tools on the same files, rules, and machine before treating any ratio as your expected time saving.
Where Does ESLint’s Plugin Ecosystem Still Lead?
ESLint’s strongest reason to remain in a project is often one plugin that catches a bug the team cannot afford to miss. Specialist coverage can matter more than raw speed when a rule guards a risky part of your app.
Plugin availability can decide a migration even when the core lint rules are covered. A replacement that catches common syntax issues may still miss a framework or test rule your team depends on.
Framework and accessibility rules
ESLint has named plugins for React, React Hooks, and jsx-a11y. These tools can check framework patterns and flag common accessibility problems in JSX. Import-management plugins can also enforce boundaries between parts of an app.
Those checks can reflect how your team builds screens, not just whether code parses. A rule that warns about a broken hook pattern may prevent a hard-to-find runtime bug. A JSX accessibility rule can flag a missing label before a user encounters it.
Testing, security, and team-specific rules
Testing plugins can check Jest or Vitest patterns, while security plugins can flag risky code. Teams can also write custom rules for conventions that are unique to their products. These rules may enforce import boundaries, naming choices, or internal APIs.
Common needs worth checking include:
- React Hooks checks
- JSX accessibility rules
- Import boundaries
- Jest or Vitest checks
- Security rules
- Custom team conventions
A team may have only one plugin that cannot be replaced. That single dependency can outweigh a faster lint command, especially when it protects a production risk. Keep a specialist ESLint rule when its finding is valuable and the replacement has not proved equivalent.
Can Biome Replace ESLint and Prettier Together?
Biome is the clearest fit when the goal is to consolidate formatting and general linting rather than preserve every ESLint plugin. One package handles formatting, linting, and import sorting, with settings in biome.json.
Biome ships 640 rules, but that count does not promise parity with every ESLint plugin or option. Biome v2.6 was released on October 15, 2026, and added more language and plugin features.
Biome vs ESLint vs Prettier is mainly a question of scope. Biome puts formatter, linter, and import sorting in one package and config file. ESLint commonly handles linting while a separate formatter, such as Prettier, handles code style.
That combination can simplify setup when your project uses general lint checks and familiar formatting options. Teams should still compare actual output, since format settings and defaults may differ. One config file is simpler only when it covers the work you need.
Biome and ESLint can also work together. A team might use Biome for formatting and general rules, then keep ESLint for specialist plugins. That division avoids forcing one tool to perform a job it cannot yet cover.
A large rule count is useful context, but counts do not measure whether the exact finding you rely on exists. Check whether each active rule has a direct replacement, not just a similar name. Check the exact rules your team uses before treating a single configuration file as a complete replacement.
What Rule Coverage and Plugins Does Oxlint Offer?
Oxlint ships enough built-in rules to cover many common JavaScript, TypeScript, React, and test-project needs. Its built-in set is broad, though it does not represent the full history of third-party ESLint plugins.
Oxlint includes 871 built-in rules across ESLint core, TypeScript, React, Jest, Vitest, Import, Unicorn, and jsx-a11y rule families. The total gives a sense of scope, not proof that every rule in your setup has a match.
Framework coverage includes React, React Hooks, React Refresh, React Compiler, React Perf, Next.js, and selected Vue rules. Testing examples include Jest and Vitest. Import rules can help with module boundaries and common import mistakes.
Its general-purpose plugin examples include ESLint core, TypeScript, Unicorn, JSDoc, Node, and Promise. The jsx-a11y set covers accessibility checks in JSX. These groups make the built-in choices easier to compare with project needs.
The official Oxlint guide describes its JavaScript and TypeScript linting features and built-in rule coverage. Some plugins or rule groups require explicit configuration, so a plugin name alone does not mean every check runs by default.
ESLint’s advantage is its wider third-party plugin history and the custom setup teams have built around it. Oxlint offers substantial native coverage without matching every plugin, parser, or local rule. Compare the enabled rules in your own configuration, since a large built-in count does not guarantee coverage of every plugin you rely on.
How Do Type-Aware Rules Change the Comparison?
Type-aware linting can slow a lint run, and Oxlint’s measured advantage is also substantial in the two type-aware benchmarks listed here. Type information adds depth: it can reveal issues ordinary syntax checks cannot determine.
Oxlint supports type-aware linting through tsgo and project-wide analysis. Tsgo is a native Go port of the TypeScript compiler, and Oxlint uses a project-wide module graph for multi-file analysis.
In the Vue Core type-aware benchmark, Oxlint took 2.531 seconds and typescript-eslint took 20.800 seconds. Oxlint measured 8.22 ± 0.19 times faster in that workload. The Sentry type-aware benchmark measured Oxlint at 4.448 seconds and ESLint at 55.070 seconds.
Oxlint measured 12.38 ± 0.27 times faster in the Sentry test. These timings compare specific setups, not every typed rule or project. Oxlint’s type-aware linting approach uses tsgo and project-wide module analysis.
Typescript-eslint uses a TypeScript compiler workflow to provide type-aware checks. Oxlint’s analysis path differs, so speed alone cannot show whether every rule behaves the same way. A migration must compare each typed rule’s result and purpose.
Type-aware rules can catch mistakes tied to actual types, such as invalid use of a value across files. They can also need more setup than basic syntax rules. Test the exact typed rules your project needs, because runtime comparisons do not establish rule-by-rule parity.
What Can Each Tool Format or Lint Beyond JavaScript?
Biome’s v2.6 language results extend beyond JavaScript, with especially strong reported compatibility for Markdown and YAML. File support matters when one repository keeps docs, settings, and styles beside source code.
Formatting support and lint-rule coverage are separate questions. A tool may format a file well without offering the lint rules your team expects for that file.
| File type | Biome v2.6 parser or test-suite result | Formatter compatibility |
|---|---|---|
| Markdown | 100% CommonMark conformance coverage | About 92% compatible with Prettier |
| YAML | 100% conformance against official test suite | 100% compatible with Prettier |
| SCSS | More than 90% compatible with official test suite | Not stated |
Biome v2.6 reports 100% CommonMark conformance coverage for its Markdown parser. Its Markdown formatter is about 92% compatible with Prettier. That gap may affect documentation diffs even when the file parses correctly.
For YAML, Biome reports 100% conformance against the official test suite and 100% compatibility with Prettier. Its SCSS support exceeds 90% compatibility with the official test suite. Those measures describe different kinds of support, so keep their labels clear.
Check every file extension that your repository actually uses, including documents and config files. A project with many Markdown files may value formatter output differently from one that mainly uses YAML. Verify each important file extension in a representative project diff before consolidating formatters.
How Do the Configuration Models Compare?
If your project uses ESLint v9 or later, flat config is already its default configuration format. Flat config puts settings in an explicit JavaScript configuration file rather than relying on the older eslintrc format.
ESLint v9.0.0 and later use eslint.config.js as the current default configuration format. Biome uses biome.json as its central config file.
The flat config name describes ESLint’s configuration model, not a promise that every plugin will transfer cleanly. Teams still need to check how rules, ignores, file matches, and shared settings work. A config file can load successfully while behaving differently from the old setup.
Flat config gives you a more direct way to define which settings apply to which files. That can help when a monorepo has several languages or packages. It does not mean every legacy config option has the same form.
Biome’s central configuration file covers its own formatter and linter settings. That can reduce scattered options when the team uses Biome for both jobs. Projects keeping ESLint may still need two config systems and clear ownership between them.
The current format should be one part of a migration plan, not its whole measure. Identify the exact config files, shared settings, and package-level overrides your project loads before changing the setup.
Can You Keep Custom Rules and ESLint Plugins?
Oxlint’s JavaScript plugin API offers an escape hatch for some ESLint rules, but the support remains alpha. Some plugins may work, but API similarity does not ensure every parser or rule can run.
Oxlint’s JavaScript plugins do not yet support custom parsers or type-aware lint rules. The API is compatible with ESLint v9 and later and supports AST traversal, fixes, rule options, selectors, scope analysis, and control-flow analysis.
It also supports inline disable directives and language-server diagnostics with quick fixes. Those features can help teams keep selected JavaScript rules while testing Oxlint. A plugin that depends on a custom parser may still need its current tool.
For example, custom parsers used with Svelte, Vue, or Angular are not supported by Oxlint’s JavaScript plugins. Rules that need TypeScript type information also fall outside that plugin support. Keep those checks in a tool that can parse and analyze their code.
Biome v2.6 introduced JavaScript and TypeScript plugins as a developer preview. Those plugins are separate from the ESLint plugin ecosystem, so teams should not assume the same compatibility. The feature status matters when deciding whether custom rules can move.
Test the actual plugin and parser combination your project uses. Check rule options and output on real files, not only whether the plugin loads. Keep any rule that depends on an unsupported parser or type information in its existing tool until an equivalent path is verified.
How Can You Migrate From ESLint to Biome or Oxlint?
Start a migration by inventorying the rules and settings the project actively uses, then choose the destination that covers them. A generated config is a starting point, not proof of identical behavior.
Review migrated rules against the original setup before removing its lint command. Biome can read legacy and flat ESLint configurations, follow extends, and load shared and plugin configurations.
Moving ESLint rules and settings into Biome
Biome’s ESLint migration command can carry over rules, globals, overrides, and ignore patterns. It enables only migrated rules by setting the rule preset to none. Review the result, since some settings or rule behavior may need a manual change.
The --include-inspired option also migrates rules inspired by ESLint rules. Their options and behavior may differ, so compare their findings. Biome’s Prettier migration ports formatter options and .prettierignore patterns, then writes options explicitly because defaults differ.
ESLint’s official migrator can create a starting point for moving eslintrc settings into eslint.config.js. It may need follow-up edits and does not work well with .eslintrc.js files. Converting to flat config first can give Oxlint a more direct starting point.
Moving ESLint rules into Oxlint
Use a short sequence to keep the work clear:
- Inventory active rules and settings.
- Run the migrator that fits the destination.
- Inspect unsupported or changed rules.
- Compare formatting diffs separately.
Keep the old command while you compare results. A converted config can omit rules that rely on plugins or behave differently after migration. Review the generated configuration against the original rule behavior before removing the existing lint command.
What Changes in Editors, CI, and Monorepos?
A migration is incomplete if CI uses the new tool while developers still receive diagnostics from the old one. Keep ownership clear so linting and formatting do not compete inside the same editor.
Editor settings and CI commands should point to the tools your team intends to use. In a monorepo, decide how root and package-level settings work before applying commands everywhere.
Local editor diagnostics and quick fixes
Editor integrations must use the intended linter and formatter. Otherwise, developers may see stale warnings or get edits from an old formatter when saving. Oxlint JavaScript plugins support language-server diagnostics and quick fixes.
Editors such as Visual Studio Code use extensions and integrated tools to support daily coding. The linter remains separate from the editor itself. Teams can compare editor options in this guide to the best code editors for developers.
Test an actual save and fix workflow, not just whether an extension starts. A working command-line check does not prove that inline diagnostics use the same configuration. Mac teams can also compare code editors for Mac when choosing their editor setup.
CI checks and repository configuration
CI should run the same intended lint command that developers use locally. You may choose to check changed files during development, then run broader checks in CI. Avoid leaving two commands that report the same findings indefinitely.
Monorepos add questions about where settings live. A root config may apply to every package, while a nested package may need different rules or file patterns. Check these three points before a broad rollout:
- Which editor owns linting?
- Which formatter runs on save?
- How do root and package configs apply?
Test one nested package and one editor save workflow before rolling the new commands out repository-wide.
Which Rules Should You Audit Before Switching?
Compare active rules, not just the names of installed packages, before deciding that a replacement is complete. The key is the finding: identify what each rule catches and whether another tool reports it.
Treat any production-relevant finding with no verified replacement as a migration gap. This check helps you avoid losing a guardrail while trimming a toolchain.
Use this checklist to focus the audit:
- Framework and React Hooks rules, including React Hooks and Next.js checks.
- Accessibility rules, such as jsx-a11y checks for JSX.
- Import restrictions and cycle checks, including Import rules.
- Test-runner rules for Jest and Vitest.
- Custom internal rules that enforce team-specific behavior.
For each item, record which rules are active and which files they affect. Then note whether each finding is unique to the current tool or duplicated elsewhere. A plugin can contain many rules your project never enables, so package names alone can overstate what you need.
Check rule options as well as rule names. Two tools may use similar names but flag different code or offer different fixes. Review a sample of real findings to see whether the replacement catches the same patterns.
Include checks for React Hooks, jsx-a11y, Jest, Vitest, Import, Next.js, and custom rules when those groups appear in your config. A gap matters most when it protects a production path or prevents recurring bugs. Treat any production-relevant finding with no verified replacement as a migration gap.
Which Tool Fits Your Project’s Priorities?
For a new project seeking one tool for formatting and general linting, Biome is the most straightforward starting point. For established apps, specialist plugin needs can make ESLint the safer choice.
Choose an Oxlint-plus-ESLint staged setup when lint speed is a bottleneck but some ESLint rules remain essential. You can use Oxlint for covered checks while preserving the specialist rules that still matter.
| Project situation | Recommended tool | Reason |
|---|---|---|
| New project seeking combined formatting and linting | Biome | One tool handles common formatting and lint tasks |
| Mature app that relies on specialist plugins | ESLint | It preserves needed plugin coverage |
| Large codebase with slow linting and essential ESLint rules | Oxlint plus ESLint, staged | Use Oxlint for covered rules and retain the rest |
The State of JS 2025 utility survey reports ESLint usage at 90%, Biome at 16%, and Oxlint at 1%. Those shares show how widely each tool is used, not which one fits a particular team. A less common choice can still suit your codebase.
For a project with no specialist rule needs, Biome can reduce the number of tools you maintain. A mature app with relied-on ESLint plugins may gain little from switching everything at once. A staged setup lets a large codebase test faster linting without dropping necessary findings.
Popularity can help you judge how familiar a tool may be to developers joining your team. It cannot replace an audit of the rules your project actually uses. Let the rules your team depends on outweigh popularity when the two point in different directions.
How Do You Validate a Switch Without Losing Coverage?
The safest test is a temporary branch where the existing checks stay in place while the candidate runs against the same files. Parallel runs show which findings each tool catches before you change the main workflow.
Keep the old command until required rules have verified replacements. This approach works for ESLint-to-Biome and ESLint-to-Oxlint trials, since you can compare both tools on one codebase.
Use four checks during the trial:
- Run current and candidate tools on the same files.
- Compare findings unique to each tool.
- Inspect formatter changes separately.
- Keep the old command until required rules have verified replacements.
Compare the results on the same file set and candidate configuration. A new tool may report fewer issues because it lacks a rule, not because the code is cleaner. Track unique findings so you can decide which ones matter.
Formatting changes should have their own review. A formatter can rewrite many lines without changing lint results, which makes it harder to judge both changes together. Review those diffs as a separate part of the trial.
Remove a check only after its unique findings and required fixes have been accounted for.
When two tools report the same problem, keeping both checks may add noise without adding coverage. Remove redundant checks only after comparing what each catches. A representative branch gives your team real results before it commits to a new system.
Conclusion
The best choice is the tool that covers your project’s important checks without making the workflow harder to maintain. Biome fits teams consolidating formatting and general linting. Oxlint suits teams that put fast linting first.
ESLint remains the practical choice when required plugin coverage is decisive. You can also use Oxlint beside ESLint while you assess which rules can move. Let real findings, not a headline speed claim, guide the change.
Run your preferred candidate beside the current setup on a representative branch, then keep it only if required findings remain covered.
FAQ
Is Oxlint faster than Biome?
Yes, Oxlint was faster than Biome in one measured benchmark. Oxlint took 138.6 milliseconds, while Biome took 377.2 milliseconds. That result describes one workload, not every project. File count, enabled rules, hardware, and configuration can change the time. Run both tools on the same files and settings to see how they compare in your repository.
Can Biome run ESLint plugins?
No, Biome does not run the JavaScript ESLint plugin ecosystem. Biome has separate JavaScript and TypeScript plugins in developer preview, but those are not the same system. If a project relies on a specialist ESLint plugin, keep ESLint for that rule unless you confirm an equivalent check. Biome can still handle formatting and general linting beside ESLint.
Can Oxlint replace ESLint completely?
Oxlint can replace ESLint rules that its built-in rules or supported plugins cover, but it cannot replace every setup automatically. Audit custom plugins, parser needs, and type-aware rules before removing ESLint. Oxlint’s JavaScript plugin support remains alpha, and those plugins do not yet support custom parsers or type-aware rules. Keep uncovered checks in their current tool.
Can Biome replace Prettier?
Yes, Biome includes a formatter and can replace Prettier for many projects, though settings and output can differ. Biome v2.6 reports about 92% compatibility with Prettier for Markdown formatting and 100% for YAML formatting. Test the file types your project uses, since a small output difference can create a large diff across documentation.
Does Biome support type-aware rules?
Yes, Biome v2 introduced type-aware rules. Compare the specific checks you need with Oxlint’s tsgo-based analysis and the typescript-eslint workflow. Their analysis paths and rule sets differ, so similar labels do not prove identical results. A small test against real typed code can show whether the rule catches the cases your team cares about.
Is ESLint flat config required to migrate to Oxlint?
No, ESLint flat config is not required, but it is the default format in ESLint v9 and later. Legacy configs may need conversion first. ESLint’s official migrator can create a starting point, though it may need follow-up edits and does not work well with .eslintrc.js files. Compare the converted settings with the current config.
Can I run Biome and ESLint together?
Yes, you can run Biome and ESLint together if each tool has a clear job. For example, Biome can handle formatting and general linting while ESLint keeps specialist rules. Compare their unique findings before removing either command, and avoid duplicate checks that add noise without new coverage. A parallel trial can show where the tools overlap.
