A Look at the JavaScript Oxidation Compiler
Oxc explained: Rust-based JavaScript and TypeScript tools, Oxlint, Oxfmt, transformer, minifier, and how it compares with ESLint, Prettier, SWC, and Biome.
Oxc, the JavaScript Oxidation Compiler, is a collection of high-performance JavaScript and TypeScript tools written in Rust, built on a shared parser and AST so that the linter, formatter, transformer, minifier, and resolver never re-parse your code independently.
If you have ever kicked off a lint run on a big monorepo, wandered off to make coffee, and come back to find it still going, you already know why a Rust rewrite of the JavaScript toolchain got so much attention. That wait, multiplied across every developer and every CI job, is most of the reason Oxc exists.
It’s the compiler layer under VoidZero’s toolchain, and as of Vite 8 it’s the machinery doing the actual language work inside every Vite build.
If your ESLint/Babel/Prettier pipeline is slow and you’ve been watching the Rust-tooling wave (esbuild, SWC, Biome, Oxc), the practical question isn’t “is Oxc fast?” It’s “which pieces are production-ready today, and where does it fit against what I already run?” This article answers that: what Oxc is, what’s in it, what you can safely adopt now, and how it lines up against the alternatives.
Key Takeaways
- Oxc is a Rust-based suite of JavaScript/TypeScript tools: parser, linter (Oxlint), formatter (Oxfmt), transformer, minifier, and resolver, all sharing one parser and AST.
- Oxlint is the standout: a stable 1.x linter that the project benchmarks at 50 to 100 times faster than ESLint, with 844 built-in rules and type-aware linting now available.
- Oxc already runs in production indirectly: Rolldown 1.0 hit stable on May 7, 2026, and Vite 8 uses Oxc for JavaScript transforms and JavaScript minification, with CSS minification handled by Lightning CSS.
- Oxfmt reached beta and now matches Prettier across its whole JavaScript and TypeScript conformance suite, though it’s still on 0.x versioning.
- The lowest-risk adoption path is running Oxlint as a fast first-pass linter alongside ESLint in CI.
What is Oxc, the JavaScript Oxidation Compiler?
Oxc is a suite of Rust-native JavaScript and TypeScript tools that share a single parser and AST, so behavior stays consistent and no tool duplicates parsing work. The name nods at Rust: rust is what metal turns into when it oxidises. Speed here is treated as something the project has to ship rather than a pleasant side effect, on the reasoning that a quicker linter means a tighter edit-and-check loop locally and a smaller CI bill.
The reason Oxc matters beyond its own CLIs is that it’s the compiler under the modern Vite stack. Rolldown is a Rust bundler, and it hands the language-level work, parsing and minification included, off to Oxc. From Vite 8 onward, all three layers are built by teams working in step: Vite as the build tool, Rolldown as the bundler, and Oxc as the compiler underneath both. So even developers who never install an Oxc package are running its parser and transformer on every build.
There’s also ownership context worth knowing before betting a pipeline on it. On June 4, 2026, Cloudflare announced it had bought VoidZero, the open-source company that maintains Vite and the tooling around it, Oxc included. Both sides say the projects stay open source and vendor-neutral, with Vite, Vitest, Rolldown, Oxc, and Vite+ all remaining under MIT licenses, and Cloudflare has put $1 million into an independent fund for Vite maintainers and contributors. VoidZero itself was set up in 2023 by Vue.js creator Evan You.
The components and what each one replaces
Discover how at OpenReplay.com.
Oxc ships as separate, composable pieces, so you can adopt one without the rest. Each targets a slow, JavaScript-based incumbent:
| Component | Replaces | Role |
|---|---|---|
| Oxlint | ESLint | Linter for JS/TS |
| Oxfmt | Prettier | Code formatter |
| Parser | Acorn / @babel/parser / tsc parse | Shared AST for all tools |
| Transformer | Babel / tsc transpile / esbuild transform | TS, JSX, modern-JS lowering |
| Minifier | Terser / esbuild minify | Production minification |
| Resolver | enhanced-resolve | Module resolution |
The parser is the anchor. Every other component reads its output, which is why Oxc can bill itself as one toolchain instead of six tools that happen to be written in Rust.
Why is Oxc fast?
Oxc’s speed comes from architecture, not micro-optimization. Three choices do most of the work. First, it’s compiled Rust rather than interpreted JavaScript, so hot paths run at native speed and avoid garbage-collection pauses. Second, all tools operate on one shared AST, eliminating the redundant re-parsing that happens when ESLint, Prettier, and Babel each parse the same file separately. Third, AST nodes are allocated in a memory arena for cheap bulk cleanup, and analysis is parallelized across CPU cores.
The payoff is measured, and the numbers are the project’s own benchmarks, so treat them as such. VoidZero reports Oxlint at 50 to 100 times faster than ESLint, Oxfmt at 30× or more Prettier’s throughput and somewhere between 2× and 3× Biome’s on a first run with no cache, and Rolldown at up to 10-30x faster builds than Rollup. The Biome number is a range because Oxc’s own sources disagree: the formatter docs quote 2×, the beta announcement 3×. Different benchmarks on different machines will land differently; the shape of the win is real, the exact multiplier is marketing until you run it on your repo.
What’s production-ready in Oxc today?
Maturity in Oxc depends on how you consume each tool. Oxlint and the parser are genuinely production-grade standalone; the transformer and minifier are pre-1.0 as CLIs but already ship in production inside Rolldown and Vite 8; Oxfmt is beta.
| Component | Status | How you consume it today |
|---|---|---|
| Oxlint | Stable, 1.x | Install directly; run in CI |
| Parser | Production-grade | Foundation under Rolldown/Vite |
| Transformer | Pre-1.0 standalone | Shipping in Vite 8 builds |
| Minifier | Pre-1.0 standalone | Default in Rolldown |
| Oxfmt | Beta, 0.x | Pilot alongside Prettier |
Oxlint is the clear standout. It shipped a stable 1.0 in June 2025, with Shopify, Airbnb, and Mercedes-Benz named in the release notes as production users, and it’s now on a 1.x line with 844 built-in rules. Oxlint also does type-aware linting: the tsgolint backend plugs TypeScript’s own type system into the Oxlint CLI and config format, and covers 59 of the 61 type-aware rules that typescript-eslint ships. The honest caveats: it’s opt-in, it needs the separate oxlint-tsgolint package installed alongside Oxlint, and that package’s version numbers track the TypeScript release it’s built against rather than Oxlint’s, so the two move on different schedules. The team has also closed the door on rules outside typescript-eslint’s set while it works on coverage and performance, which rules out custom type-aware rules for now.
Don’t read “the transformer and minifier are pre-1.0” as “not production-ready.” Both already run under every Vite 8 build. The Vite 8 migration guide spells out the division of labour: Oxc took over JavaScript transformation and JavaScript minification from esbuild, while Lightning CSS became the default for minifying CSS. Oxfmt, meanwhile, moved from alpha to beta and now clears Prettier’s entire JavaScript and TypeScript conformance suite, but npm still labels it Beta, so it’s a pilot, not a wholesale Prettier rip-out yet.
How Oxc compares to SWC and Biome
The most common comparison mistake is framing Oxc against SWC on speed. They occupy different layers. SWC is a compiler platform that frameworks embed: Next.js owns its SWC seam, and you shouldn’t rip that out chasing a benchmark chart. Oxc’s transformer competes with SWC and Babel, but SWC has no first-party linter or formatter, so Oxlint competes with ESLint and Biome, not SWC. Biome is the closer rival: a Rust tool that does lint and format in one binary, whereas Oxc keeps Oxlint and Oxfmt as separate composable pieces.
Given that, the pragmatic move is to adopt Oxlint now and watch the rest. Run it as a fast first pass in CI while keeping ESLint for the rules and plugins it doesn’t yet cover:
{
"scripts": {
"lint:fast": "oxlint",
"lint": "oxlint && eslint ."
}
}
To reduce overlap, the docs point to @oxlint/migrate for translating an existing ESLint config, plus eslint-plugin-oxlint to disable rules Oxlint already handles. This gets you the speed win on the fast path without giving up ESLint’s coverage on the full run.
Oxc has crossed from “promising Rust project” into infrastructure that millions of builds already depend on, but not evenly across its surface. Start with Oxlint (stable, fast, and low-risk alongside your current linter), pilot Oxfmt on a branch to check the diff, and let the transformer and minifier reach you through Vite 8 rather than adopting them standalone. Reassess the pre-1.0 pieces as they graduate; the direction of travel is clear enough to plan around.
FAQs
Can I run Oxlint and ESLint together, or do I have to choose one?
You can run both, and running both is the recommended adoption path. Use Oxlint as a fast first pass in CI and keep ESLint for the rules and plugins Oxlint does not yet cover. The Oxc docs point to '@oxlint/migrate' to translate an existing ESLint config and 'eslint-plugin-oxlint' to disable ESLint rules Oxlint already handles, which removes duplicate work while you run both linters.
Does Oxc replace SWC, and should I remove SWC from Next.js to use it?
No. Oxc's transformer competes with SWC and Babel, but you should not rip SWC out of a framework that embeds it, such as Next.js, chasing a benchmark. SWC is a compiler platform frameworks own internally, and SWC has no first-party linter or formatter, so Oxlint competes with ESLint and Biome rather than SWC. The safe adoption surface is Oxlint, not swapping a framework's built-in compiler.
What is the difference between Oxc and Biome?
Biome is a single Rust binary that does both linting and formatting, while Oxc keeps its linter (Oxlint) and formatter (Oxfmt) as separate, composable pieces you can adopt independently. Oxc is also broader: it includes a parser, transformer, minifier, and resolver that power Rolldown and Vite 8, whereas Biome focuses on the lint-and-format layer. On an uncached initial run, VoidZero benchmarks Oxfmt at roughly 2 to 3 times faster than Biome; the Oxfmt docs and the beta announcement quote different figures for that comparison.
Does the Cloudflare acquisition of VoidZero change whether Oxc stays open source?
No. Cloudflare acquired VoidZero on June 4, 2026, and both companies state the projects remain open source and vendor-neutral. Vite, Vitest, Rolldown, Oxc, and Vite+ stay under MIT licenses, and Cloudflare committed 1 million dollars to a new independent Vite ecosystem fund for maintainers and contributors who are unaffiliated with either VoidZero or Cloudflare. The MIT licensing means existing forks and usage are unaffected regardless of ownership.
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers.
Star on GitHub12k