# microcharts vs Recharts — inline charts comparison (/docs/vs-recharts)

[Recharts](https://recharts.org) is a full chart library and microcharts is not a replacement for it. If your page _is_
the chart — axes, legend, tooltip, brush — stop reading and use Recharts. This page compares the two for exactly 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](/docs/when-to-use) and
[Full chart libraries](/docs/full-chart-libraries). This page is the measured detail for the Recharts decision.

## The numbers

<VsRechartsTable />

Both microcharts columns come from `.size-limit.json`, the CI gate that fails the build when a chart grows past its
budget. The Recharts numbers are pinned with version, method, and date — they are orientation, not a scoreboard, and
they will age.

## Where the difference actually shows

**Bundle cost per mark.** A tree-shaken Recharts `LineChart` carries the shared Recharts core. That cost is fine
amortized over a dashboard; it is 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 — 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. microcharts
hard-codes them away because word-sized marks cannot afford them. Neither choice is a defect; they 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: <SizeMarketing /> gzip, zero runtime dependencies

## Same app, both libraries

This is the common ending, not a compromise:

```tsx
// 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} />;
```

## What this page is not saying

- Not "Recharts is heavy" — it is correctly sized for the job it does
- Not "microcharts can replace your dashboards" — it cannot and does not try
- The gzip figures are dated pins, not live measurements

## Next

- [Full chart libraries](/docs/full-chart-libraries) — Recharts and Chart.js in one view
- [When to use microcharts](/docs/when-to-use) — the product decision
- [microcharts vs Chart.js](/docs/vs-chartjs)
- [Performance](/docs/performance) — our own CI receipts