A fast stream of formatted code on a monitor with a gray-blue cat watching calmly from the desk.

Oxfmt: Prettier's Output at Rust Speed

The Gray Cat
The Gray Cat
 0 views

If you have ever waited for Prettier to chew through a large monorepo, you already understand the pitch behind Oxfmt. It is a code formatter that produces the same output you already expect from Prettier, but it is written in Rust and runs roughly thirty times faster. It comes from the Oxc project (the Oxidation Compiler), the same Rust-based JavaScript toolchain that gave us the oxlint linter, and it is backed by VoidZero, the company stewarding Oxc.

The promise is unusually specific: a near drop-in replacement for Prettier. You keep your existing config, you keep your existing formatted output, and in exchange you get an order-of-magnitude speed gain plus a handful of features that previously required separate plugins. Import sorting, Tailwind class sorting, and package.json field sorting are all built in. One binary instead of a stack of tools.

A fair word of caution up front: Oxfmt is still beta at version 0.54.0 and pre-1.0. It is ready to try and watch closely, not something to rip out of a production pipeline without testing. With that framed, let us look at what it does.

Why It Is Worth Your Attention

The headline is speed, and the numbers come from the Oxc team's own benchmarks measured on a real repository:

  • Around 30x faster than Prettier on an uncached run.
  • Around 3x faster than Biome, the other major Rust-based formatter, on an initial uncached run.

That speed comes from three places: a Rust implementation, the Oxc parser (one of the fastest JavaScript parsers around), and multi-threaded file processing. On the Node side the only meaningful runtime dependency is tinypool, a worker thread pool; the actual formatting is done by a prebuilt platform-specific Rust binary.

The second reason is compatibility. The beta release claims 100% Prettier compatibility, passing all of Prettier's JavaScript and TypeScript conformance tests. The Oxc team actively collaborates with Prettier's maintainers, filing bug reports and patches that have shaped recent Prettier releases. The practical payoff is migration with minimal or zero diffs: you switch formatters and your codebase barely changes.

The third reason is consolidation. Several things that are separate Prettier plugins ship inside Oxfmt:

  • Tailwind CSS class sorting, replacing prettier-plugin-tailwindcss.
  • Import sorting, with configurable grouping and side-effect handling.
  • package.json field sorting, on by default.

And the file-type coverage is broad. Beyond JavaScript, JSX, TypeScript, and TSX, the beta formats JSON, JSONC, JSON5, YAML, TOML, HTML, CSS, SCSS, Less, Markdown, MDX, GraphQL, Vue, Angular, Ember, and Handlebars. It even handles embedded languages like CSS-in-JS in styled-components and styled-jsx. The goal is a single formatter for the entire project.

Getting It Into Your Project

Oxfmt installs as a dev dependency and fetches the right prebuilt binary for your platform.

# npm
npm add -D oxfmt@latest

# yarn
yarn add -D oxfmt

Once installed, the command-line interface is deliberately small. Running the binary with no arguments formats your files in place:

# format files in place
oxfmt

# check formatting without writing anything (great for CI)
oxfmt --check

# scaffold a config file
oxfmt --init

Most teams wire it into package.json scripts so nobody has to remember the flags:

{
  "scripts": {
    "fmt": "oxfmt",
    "fmt:check": "oxfmt --check"
  }
}

The --check mode is the one your continuous integration job wants. It exits with a non-zero status if any file is not already formatted, without touching the working tree, so a misformatted commit fails the build instead of silently slipping through.

Switching Over From Prettier

The migration story is the part that makes Oxfmt approachable. There is a dedicated command that reads your existing Prettier configuration and converts it:

oxfmt --migrate prettier

If you are coming from Biome instead, the same mechanism works:

oxfmt --migrate biome

Because Oxfmt accepts Prettier-style option values, the conversion is often as simple as renaming .prettierrc.json to .oxfmtrc.jsonc and letting Oxfmt read it. A typical config looks reassuringly familiar:

{
  // Oxfmt understands Prettier-style options directly
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100
}

There is one default worth flagging before you migrate: Oxfmt defaults printWidth to 100, while Prettier defaults to 80. If you want byte-for-byte identical output to your current Prettier setup, set printWidth explicitly to whatever your project uses. This single difference accounts for most of the surprise diffs people hit on day one, so it is the first thing to check.

Oxfmt also consolidates a couple of things that used to live in separate files. An ignorePatterns field handles what you would otherwise put in .prettierignore, and overrides lets you apply different options to different file patterns from the same config. It reads .editorconfig as well.

Sorting Imports Without a Plugin

One of the nicer wins is that import sorting is native, so you can retire the ESLint or Prettier import-order plugins you were leaning on. It is configurable through the same config file, with control over case sensitivity, how side-effect imports are treated, blank-line behavior between groups, and custom grouping.

The effect is the kind of thing you stop thinking about once it works. Given a messy block like this:

import { z } from "zod";
import React from "react";
import { formatDate } from "./utils/date";
import clsx from "clsx";
import { Button } from "@/components/Button";

Oxfmt rearranges the imports into consistent, grouped order on every save and every CI run, so reviews stop filling up with reorder-only diffs. Combined with the built-in Tailwind class sorting, a lot of the noise that normally collects in pull requests simply disappears, and it disappears without you assembling a chain of plugins to make it happen.

Editors, CI, and Calling It From Code

The beta ships full editor integration through a language server, so format-on-save works in the usual places: VS Code, Cursor, Zed, IntelliJ IDEA, WebStorm, Neovim, and anything else that speaks LSP. That makes the local developer experience effectively identical to a Prettier setup, just faster.

There is also a programmatic Node.js API added in the beta, for cases where you need to format a string of code from inside your own tooling rather than running the CLI over files. Conceptually it looks like this:

import { format } from "oxfmt";

const source = `const   x={a:1,b:2}`;

const formatted = await format(source, {
  printWidth: 100,
  singleQuote: true,
});

console.log(formatted);

The API surface is still settling as the project moves toward 1.0, so check the current Oxfmt docs for the exact signature before you build something on it. For the common case, though, the CLI plus the editor extension covers everything most teams need.

In a CI pipeline the pattern is straightforward: install Oxfmt as a dev dependency and run the check command as a gate.

# fails the build if anything is not formatted
oxfmt --check

Because the run is so fast, you can afford to format the whole repository rather than just the changed files, which sidesteps a whole category of "it passed locally but not in CI" confusion.

A Few Honest Caveats

Oxfmt is genuinely usable today, but it is beta software and deserves to be treated like it. Some defaults and CLI options still differ from Prettier, and you may occasionally hit a formatting edge case where output diverges. The team explicitly asks people to report those discrepancies, which is part of how the compatibility number has climbed.

The roadmap points toward Prettier plugin support, better embedded-language formatting, and continued stability work. It ships weekly alongside oxlint under the Oxc release train, so fixes land quickly. If you want a sense of where it sits relative to neighbors: Prettier remains the incumbent and the compatibility target, with the largest plugin ecosystem; Biome is a broader linter-plus-formatter toolchain with its own opinionated style rather than Prettier parity; and dprint is another fast Rust formatter with a different config model. Oxfmt's distinct position is being formatter-only and laser-focused on matching Prettier's output while running much faster, with linting left to its sibling oxlint.

Wrapping Up

Oxfmt is the formatting half of a thesis that oxlint already proved for linting: you can rewrite JavaScript tooling in Rust and get dramatic speed without asking developers to learn a new style. Keep your Prettier config, keep your output, gain roughly thirty times the speed, and collapse three plugins into one binary that also formats your CSS, YAML, and Markdown.

For a side project or a willing team, it is well worth trying right now. For a large production pipeline, adopt it the way you would adopt any beta: pin the version, run it in --check mode first to compare diffs, and report anything that looks off. With VoidZero behind it and weekly releases shipping, Oxfmt has a clear home and an obvious trajectory. Watch this one closely.