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

[Recharts](https://recharts.org) 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](/docs/when-to-use) and
[Full chart libraries](/docs/full-chart-libraries). What follows 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 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: <SizeMarketing /> 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:

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

## 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