Oxc vs SWC: Rust JS Toolchains Compared 2026

Two Rust-based JavaScript toolchains are competing to replace the JavaScript-based tools that have dominated the ecosystem for years. SWC has been doing this longer — it powers Next.js's compiler, is used by Parcel and Deno, and has been running production JavaScript at scale since 2020. Oxc is newer and faster in every measured benchmark, shipping a parser that beats SWC by 3x, a transformer that's 4x faster, and a linter that makes ESLint look like it's running in slow motion.

But benchmarks aren't the whole story. SWC is embedded deep in the JavaScript ecosystem. Oxc is building toward completeness. Here's where each actually wins.

TL;DR

For new projects choosing a transform pipeline or linter: Oxc — it's objectively faster across every benchmark category, has a smaller installation footprint (2MB vs 37MB), and its linter is the most compelling replacement for ESLint available. Oxlint at 50-100x faster than ESLint isn't marketing math — it's the difference between a 30-second lint step and a sub-second one. For projects running Next.js, Parcel, or Deno: SWC is already your toolchain — these frameworks vendor or depend on SWC, and there's nothing to switch. For standalone bundling use cases: Rolldown (also from the Oxc/VoidZero ecosystem) is now the better choice over both.

Key Takeaways

Oxc parses JavaScript 3x faster than SWC: 26.3ms vs 84.1ms on a TypeScript/React codebase (M3 Max)
Oxc transformer is 4x faster: 47ms vs 193ms for a 10,000-file transform
Oxlint is 50-100x faster than ESLint: a 400ms ESLint run becomes 4-8ms with Oxlint
Oxc weighs 2MB installed vs SWC's 37MB — 18x smaller footprint
SWC powers Next.js — if you use next build, you're already using SWC; you can't switch this to Oxc
Both are written in Rust — the architecture is similar, but Oxc used SWC's design as a learning opportunity and made different trade-offs
VoidZero umbrella: Oxc, Rolldown, Vitest, and Vite are all under Evan You's VoidZero org — these tools are designed to compose
SWC's Turbopack integration: Vercel is building Turbopack (Next.js's future bundler) on SWC's architecture

At a Glance

	Oxc	SWC
Language	Rust	Rust
Parse speed (TypeScript/JSX)	26.3ms	84.1ms (3x slower)
Transform speed (10k files)	47ms	193ms (4x slower)
Lint speed vs ESLint	50-100x faster	N/A (no linter)
Installed size	~2MB	~37MB
Next.js integration	❌	✅ (built-in)
Parcel integration	❌	✅ (built-in)
Deno integration	❌	✅ (built-in)
Standalone bundler	Rolldown (sister project)	✅ `@swc/core` + bundler
Linter	✅ Oxlint	❌
Minifier	✅ (Oxc Minifier)	✅ (experimental)
Plugin API	In progress	✅ (Wasm plugins)
npm downloads/week	~3M	~25M
Backing	VoidZero (Evan You)	Vercel (SWC core team)

The Architecture Difference

Both Oxc and SWC solve the same problem: JavaScript tooling written in JavaScript is slow because it pays JavaScript's startup costs and single-thread limitations to process JavaScript. Moving the tooling to Rust (a compiled native language) means no runtime, no GC pauses, and the ability to parallelize across multiple CPU cores.

Where they differ is in design philosophy:

SWC built a general-purpose JavaScript compilation platform with a Babel-compatible architecture. The goal was to be a drop-in replacement for Babel with much better performance. It succeeded — Next.js replaced Babel with SWC in Next.js 12, reducing Fast Refresh times by ~10x and production build times significantly.

Oxc studied SWC's architecture and made different trade-offs: a stricter module boundary between components (parser, transformer, linter, resolver are all separate crates that can be used independently), more aggressive use of Rust's zero-copy memory model, and tighter integration between the parser and linter for semantic analysis.

SWC architecture:
  swc_core
    ├── swc_ecma_parser    (JS/TS parser)
    ├── swc_ecma_transform (transforms)
    ├── swc_ecma_minify    (minification)
    └── swc_bundler        (bundler core)

Oxc architecture (modular, each independently usable):
  oxc
    ├── oxc_parser         (fastest parser)
    ├── oxc_transformer    (transforms)
    ├── oxc_linter         (Oxlint — 500+ rules)
    ├── oxc_minifier       (minifier)
    ├── oxc_resolver       (module resolution)
    └── oxc_codegen        (code generation)

The modular design means you can use oxc_parser in your own Rust tool without pulling in the entire Oxc toolchain. This is how Rolldown uses Oxc — it uses the Oxc parser and resolver as components, not as a dependency on the full Oxc suite.

Parser Benchmark

Benchmark: Parse TypeScript + JSX application source
Machine: Apple M3 Max
File: typescript/src/compiler/checker.ts (~3.9MB)
Iterations: 100 runs, median

Oxc (oxc_parser):         26.3ms
SWC (swc_ecma_parser):    84.1ms   (+220%)
Babel (@babel/parser):    853ms    (+3,143%)
TypeScript (tsc parser):  293ms    (+1,014%)

The 3x gap between Oxc and SWC on parsing is consistent across different input sizes. The architectural reason: Oxc's parser uses a more aggressive arena allocation strategy that reduces heap allocation pressure during parsing, and makes better use of SIMD instructions for string scanning on modern ARM and x86-64 processors.

For applications doing incremental builds on large codebases, parse speed is the bottleneck — every file change requires re-parsing the changed file and its affected imports.

Transform Speed

Benchmark: Transform 10,000 TypeScript + JSX files to ESM
Machine: Apple M3 Max (10 cores utilized)

Oxc Transformer:    47ms
SWC Core:          193ms   (+311%)
esbuild (Go):      180ms   (+283%)
Babel:             22,000ms (+46,709%)

The Oxc transformer and esbuild are in the same performance tier (both native, both multi-threaded). SWC is ~4x slower than Oxc but still 100x faster than Babel. For most projects, all three native transformers are "fast enough" — the difference between 47ms and 193ms matters when you're processing millions of files in a monorepo CI pipeline, not for a 200-file application.

Oxlint: The ESLint Replacement

This is Oxc's most compelling near-term use case. ESLint is slow. Not "could be faster" slow — genuinely, practically slow for large codebases:

# Real-world lint times (600-file TypeScript monorepo):
eslint . --ext .ts,.tsx      # 8-12 seconds
oxlint .                     # 0.08-0.12 seconds (100x faster)

# The same rules, the same files, 100x faster

Oxlint ships with 500+ rules covering the most important ESLint, eslint-plugin-react, eslint-plugin-unicorn, and TypeScript-ESLint rules. You run it alongside ESLint today, or as a full replacement for projects willing to verify their rules are covered:

// package.json — run Oxlint first (fast), ESLint for remaining rules
{
  "scripts": {
    "lint": "oxlint . && eslint . --ext .ts,.tsx",
    "lint:fast": "oxlint ."
  }
}

# Install
npm install --save-dev oxlint

# Run (zero config — reads from .oxlintrc.json if present)
npx oxlint .

# With specific rules
npx oxlint --deny correctness --deny suspicious .

The zero-config story is real: npx oxlint . on a standard TypeScript project will find real issues without any configuration file. The rule categories (correctness, suspicious, perf, style, pedantic) let you enable groups rather than listing rules.

// .oxlintrc.json — minimal config
{
  "rules": {
    "no-unused-vars": "error",
    "no-undef": "error",
    "react/hooks-exhaustive-deps": "warn"
  },
  "env": {
    "browser": true,
    "node": true
  }
}

Rules Coverage

Oxlint rule coverage (as of early 2026):
  ESLint core rules:        ~180 rules (most critical ones covered)
  TypeScript-ESLint:        ~90 rules
  eslint-plugin-react:      ~60 rules
  eslint-plugin-unicorn:    ~50 rules
  jsx-a11y:                 ~30 rules
  eslint-plugin-import:     ~20 rules

Total: 500+ rules

What's missing:
  - Some project-specific custom ESLint rules
  - eslint-plugin-testing-library
  - Some advanced TypeScript-ESLint type-aware rules
  (these require the full TypeScript language server)

SWC in the Next.js Ecosystem

For Next.js users, SWC isn't a choice — it's the default compiler since Next.js 12, and it's not replaceable:

// next.config.js — SWC is the default
/** @type {import('next').NextConfig} */
const nextConfig = {
  // SWC minification (default in Next.js 13+)
  swcMinify: true, // true by default, option deprecated/removed in Next 14

  // SWC compiler options
  compiler: {
    // Remove console logs in production
    removeConsole: process.env.NODE_ENV === "production",

    // styled-components transform (SWC replaces babel-plugin-styled-components)
    styledComponents: true,

    // Emotion support
    emotion: true,
  },
};

export default nextConfig;

Next.js's SWC integration covers: TypeScript stripping, JSX transformation, styled-components/emotion CSS-in-JS transforms, fast refresh transforms, and production minification. These are deeply integrated — swapping Oxc into a Next.js project isn't possible today.

Vercel is building Turbopack (the Rust bundler that will replace webpack in Next.js) on top of SWC's infrastructure. If you're all-in on the Next.js/Vercel ecosystem, SWC is your present and future.

Oxc for Library Authors

For library authors building npm packages, Oxc's standalone tools are increasingly useful:

// Using Oxc's Node.js bindings for custom transforms
import oxc from "oxc-transform";

// Transform TypeScript to ESM
const result = oxc.transform("src/index.ts", source, {
  typescript: {},
  jsx: { runtime: "automatic" },
  sourcemap: true,
});

console.log(result.code);    // Transformed JS
console.log(result.map);     // Source map
console.log(result.errors);  // Any errors

For build scripts that need to transform TypeScript files without the weight of a full bundler, oxc-transform (2MB installed) vs @swc/core (37MB) is a significant difference in CI image size.

The VoidZero Ecosystem

Oxc's roadmap is deeply connected to the VoidZero ecosystem:

VoidZero tools (all designed to compose):
  Oxc          → Parser, transformer, linter, resolver
  Rolldown     → Bundler (uses Oxc's parser + resolver internally)
  Vitest       → Test runner (will use Oxc for transforms)
  Vite 8+      → Dev server + build tool (uses Rolldown)

Oxc is the shared language infrastructure layer for this ecosystem. When Rolldown bundles your application in Vite 8, it's using Oxc's parser under the hood. When Vitest migrates from esbuild to Oxc for transforms, the entire ecosystem converges on a single parsing implementation.

This composability is intentional. Where SWC was designed as a self-contained replacement for Babel, Oxc was designed as infrastructure that other tools build on.

SWC's Wasm Plugin API

SWC has a feature Oxc doesn't yet: a WebAssembly plugin API that lets you write custom transforms in any language that compiles to Wasm:

// next.config.js — custom SWC transform via Wasm plugin
const nextConfig = {
  experimental: {
    swcPlugins: [
      ["my-custom-transform", { /* options */ }],
    ],
  },
};

This enables the ecosystem to build SWC plugins the same way Babel plugins work, but compiled to native speed. The plugin ecosystem is still smaller than Babel's, but it exists and is growing.

Oxc's plugin API is in development. Until it ships, projects that depend on custom Babel transforms to switch to SWC plugins will need to stay with SWC.

Installed Size in Practice

# Check installed sizes
du -sh node_modules/@swc/core
# 37MB (including platform-specific native binary)

du -sh node_modules/oxc-transform
# 2MB (smaller native binary, less code)

# For a typical CI pipeline running on Linux x64,
# this affects Docker image sizes when you cache node_modules

For teams optimizing CI image sizes or running in memory-constrained environments (Lambda, Cloudflare Workers build stages), 35MB matters. For most projects it doesn't.

Which to Choose

Choose Oxc when:

Adding a linter to a project — Oxlint is the fastest ESLint alternative available, and the 500+ rule coverage handles most real-world linting needs
Building Node.js libraries or CLIs where you control the build pipeline and want the fastest transform step
Using Vite 8 / Rolldown — Oxc is already in your stack as Rolldown's parser
You care about installed size in CI or edge environments (2MB vs 37MB)
Building tools that need a fast JS/TS parser as a library component

Choose SWC when:

Using Next.js — it's built in, you have no choice, and it's excellent
Using Parcel or Deno — same situation
You need Wasm-based custom transforms (SWC plugins) without waiting for Oxc's plugin API
Your toolchain is deep in the SWC plugin ecosystem
Deploying to Vercel and using their Turbopack-based future features

The most common real-world stack in 2026:

# Vite 8 project: Oxc is already present (via Rolldown)
npm install vite@8

# Add Oxlint for linting
npm install --save-dev oxlint

# Result: Oxc's parser powers Rolldown, Oxlint handles linting
# No SWC needed in this stack

Compare Oxc and SWC download trends at PkgPulse.