microcharts vs Recharts — inline charts comparison

Recharts is a full chart library, and microcharts does not replace it. If your page is the chart, with axes, a legend, a tooltip, and a brush, use Recharts. This page compares the two for one job: a word-sized chart inside an interface, where the surface is mostly words and UI.

The broader positioning lives in When to use microcharts and Full chart libraries. What follows is the measured detail for the Recharts decision.

The numbers

Orientation only — different jobs. Recharts package via bundlephobia 2026-07; one-chart via esbuild tree-shake 2026-07. microcharts from .size-limit.json (CI).

Both microcharts columns come from .size-limit.json, the CI gate that fails the build when a chart grows past its budget. The Recharts figures are pinned with version, method, and date. They are dated orientation rather than live measurements, and they will age.

What differs

Bundle cost per mark. A tree-shaken Recharts LineChart carries the shared Recharts core. That cost is fine amortized over a dashboard, and hard to justify for one sparkline in a table header. microcharts imports one chart per subpath, so a page that uses only Sparkline pays only for Sparkline.

Server Components. Recharts components are hook-based, so in an App Router app they run inside a client boundary and ship their JavaScript. The microcharts default export is hook-free static SVG: it renders in an RSC with zero client JavaScript, and interactivity is a separate opt-in /interactive import.

Accessibility defaults. Recharts ships an accessibility layer, on by default in v3, with keyboard navigation and ARIA roles on the chart surface. A natural-language description of the data is still yours to write. Every microchart is role="img" with that description generated from the data by default (describeSeries); the decorative opt-out is explicit (summary={false}).

Chart chrome. Recharts draws axes, ticks, legends, and tooltips because dashboard surfaces need them, and it is sized correctly for that job. microcharts hard-codes them away because word-sized marks cannot afford them. The two libraries serve different surfaces.

Reach for Recharts

• The page is mostly chart: analytics views, report panels, explorable dashboards
• You need ticks, legends, brush, zoom, or a tooltip that follows the pointer
• Your team already has a Recharts component tree it trusts

Reach for microcharts

• The mark sits in a sentence, a table cell, a tab, a KPI card, or a streamed AI reply
• You want static chart SVG out of a React Server Component with nothing to hydrate
• You want an accessible name generated from the data without wiring it per chart
• Budget matters per mark: ~2–7 kB interactive · ~1–4 kB static gzip, zero runtime dependencies

Same app, both libraries

Most apps that need both end up here. Recharts on the analytics page, microcharts in the table that links to it:

// analytics page — Recharts
<ResponsiveContainer width="100%" height={240}>
  <LineChart data={rows}>…</LineChart>
</ResponsiveContainer>;

// the table that links to it — microcharts
import { Sparkline } from "@microcharts/react/sparkline";
<Sparkline data={row.series} width={72} height={16} dots="none" summary={false} />;

Next

• Full chart libraries — Recharts and Chart.js in one view
• When to use microcharts — the product decision
• microcharts vs Chart.js
• Performance — our own CI receipts