Recharts: React Chart Components Built on D3

What Recharts solves for React developers

Recharts exists so that a chart in a React app is written as JSX rather than assembled imperatively. The README states the library is built with React and D3, and lists three principles: deploy simply with React components, native SVG support with minimal dependencies, and declarative components. The audience is anyone rendering data visualisation inside a React tree, particularly single-page applications, since the README recommends npm as the installation method for SPAs and notes it pairs with a CommonJS bundler such as Webpack.

The practical consequence is that a chart is a parent element with children. The README example puts a LineChart around an XAxis, a Tooltip, a CartesianGrid and two Line children, each of which is an independent React component. The README calls this separation and composition one of the principles the library follows. That matters when a chart needs a custom tooltip, a different axis, or a legend in a specific place: you add or replace a child instead of reaching into an options object.

It is not a general plotting toolkit. There is no Python binding, no server-side rendering pipeline described in the README, and no canvas renderer mentioned. If your data lives in a notebook or your output is a static image file, this is the wrong layer.

How the component model and D3 split the work

The architecture visible in the README is a composition tree. LineChart is the container; XAxis, Tooltip, CartesianGrid and Line are siblings inside it. Each child is a React component, and the README describes the separation of components as a principle rather than an implementation detail. D3 supplies the underlying calculations, and React supplies the rendering and the update path.

What the README does not do is spell out the internal data flow: it never documents how props are aggregated from children into the parent, how scales are computed, or what happens on a resize. Those details live in the documentation site and the storybook, both linked from the README. Treat the README as a map of the public surface, not as a specification of behaviour.

The repository layout supports the same reading. The src directory holds the library source, the storybook directory holds component stories, test-vr holds visual regression tests, and www holds the documentation site as a workspace. The package.json exposes three build outputs: lib for CommonJS, es6 for ES modules, and types for TypeScript declarations, with sideEffects set to false so bundlers can tree-shake. For a TypeScript consumer, the types field points at types/index.d.ts, which is generated by the build-types script before the other build steps run.

Installing Recharts and rendering a first chart

The README gives npm as the recommended path. Note the second package: react-is is installed alongside recharts, and the README states it needs to match the version of your installed react package. That is the first thing to get wrong in a real project, because a mismatched react-is usually surfaces as a runtime error rather than a build failure.

npm install recharts react-is

After installation, a minimal chart is the README example: a LineChart with explicit width and height, an XAxis bound to a dataKey, a Tooltip, a grid, and two Line series. The data prop is an array of objects, and each Line names the field it plots through dataKey.

<LineChart width={400} height={400} data={data}>
  <XAxis dataKey="name" />
  <Tooltip />
  <CartesianGrid stroke="#f5f5f5" />
  <Line type="monotone" dataKey="uv" stroke="#ff7300" />
  <Line type="monotone" dataKey="pv" stroke="#387908" />
</LineChart>

What you should see is an SVG line chart with two series, an x axis labelled from the name field, a tooltip on hover, and a light grid. The width and height props are set on the container, so the chart does not size itself to its parent in this example.

Deno users are covered too. The README says Deno is a drop-in replacement for npm and gives the equivalent command:

deno add recharts react-is

There is also a UMD build on unpkg for pages without a bundler. The README shows three script tags for react, react-dom and react-is at version 18, followed by the Recharts UMD bundle, after which the library is available on window.Recharts.

<script src="https://unpkg.com/react@18/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js"></script>
<script src="https://unpkg.com/react-is@18/umd/react-is.production.min.js"></script>
<script src="https://unpkg.com/recharts/umd/Recharts.js"></script>

Where the declarative model gets in the way

The first limitation is coverage. Because every chart is a set of named components, anything the component set does not expose has to be built from primitives or dropped. The README lists LineChart, XAxis, Tooltip, CartesianGrid and Line in its example, and points to the documentation site and storybook for everything else. It does not enumerate the full component catalogue, so a team evaluating the library for an unusual visualisation should check the storybook before committing, not after.

The second is the dependency pairing. The README is explicit that react-is must match the installed react version. This is a constraint that shows up in monorepos and in apps that pin React through a shared config: you can end up with a working build and a broken chart, because the mismatch is a runtime concern.

The third is the rendering target. The README describes native SVG support as a principle. SVG means DOM nodes per element, which is fine for dashboards and interactive charts and less fine for thousands of points redrawn at high frequency. The README does not present a canvas mode, so if your requirement is a canvas renderer, this is not the library for that requirement.

Finally, versioning. The current release line in the repository is v3.11.0-canary.3, and the README notes that all development happens on the main branch while the latest release and storybook reflect the release branch. If you read a fix in the main branch, it is not necessarily in the version you installed.

Recharts compared with ECharts and Chart.js

The difference from ECharts is the programming model rather than the chart list. ECharts is configured through an options object passed to an imperative API; Recharts is composed from React components with props. In a React codebase the Recharts approach keeps chart configuration inside the component tree, which is why the README leads with declarative components as a principle. The trade-off is that an options-object library can expose a much larger surface of chart types and behaviours through one entry point, while a component library has to ship a component for each concept.

Compared with Chart.js, the split is similar but the rendering target differs. Chart.js draws to canvas, which handles dense series differently from SVG. Recharts builds native SVG, which means chart elements are part of the DOM and can be styled and inspected the way other DOM elements are. Neither approach is universally better; the choice follows from how many points you draw and whether you need CSS-level control over chart parts.

One practical consideration for React specifically: because Recharts components are ordinary components, they participate in the same rendering and reconciliation path as the rest of your UI. That is the whole point of the library, and it is also why the react-is version constraint exists.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-19. Releases in the repository are currently on the v3.11.0-canary line, with v3.11.0-canary.3 published on 2026-09-09. Canary releases are pre-release tags, so the version you install from npm may not be the version being cut on main.

The README states that all development is done on the main branch and that the current latest release and storybook documentation reflect what is on the release branch. That is a useful boundary when you are deciding whether a bug you hit is already fixed: the fix may exist on main and not in your installed version. It also means the storybook is a reasonable place to check current behaviour without reading source.

Licence is MIT, and the README carries a copyright line for Recharts Group covering 2015 to 2026. MIT is permissive, which generally means you can use the library in commercial and closed-source applications provided you keep the copyright and permission notice. That is a description of the licence text, not legal advice; if your organisation has a policy on third-party notices, run it past whoever owns that policy.

Upgrade cost is dominated by the React pairing rather than by Recharts itself. Because react-is must match your react version, any React upgrade is also a Recharts verification step. The build pipeline in package.json produces four artifacts (types, CommonJS, ES modules and a UMD bundle) and runs a test-build-output step afterwards, so published packages carry all four; consumers pick the one their tooling understands.

Who should adopt Recharts, and what to check first

Adopt it if your application is already React, your charts are part of the UI rather than a separate reporting service, and you want chart configuration to live in JSX next to the components that own the data. The README's composition example is the clearest signal of intent: a chart is a tree you assemble, and each piece is replaceable.

Do not adopt it if you need a canvas renderer for very dense data, if your charts are generated outside a React tree, or if your required visualisation is not represented in the component catalogue. Check the storybook and documentation site, both linked from the README, before you commit to a design that depends on a chart type you have not confirmed exists.

Before installing, verify two things. First, the react-is version that will land in your lockfile relative to your react version, since the README states they must match. Second, whether the behaviour you are targeting is on the release branch or only on main, because the README states development happens on main while releases and the storybook reflect the release branch. If you are pinning to a canary such as v3.11.0-canary.3, treat the pin as temporary and re-check the release branch before you ship.

Editorial conclusion

Recharts fits teams already writing React who want charts as components and are willing to keep react-is aligned with react. It is the wrong pick when you need chart types the component set does not cover, or when you want a canvas renderer for very dense series, since the library builds native SVG. Before adopting, verify the react-is version match in your lockfile, confirm the chart type you need exists in the current release, and check whether the main branch or the release branch reflects the behaviour you are targeting.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. recharts/recharts on GitHub
5. Releases