Highcharts React: a JSX wrapper where the chart is a component tree

Charts as JSX, not as a config object

The design decision that defines this library is that a chart is a React component tree rather than a configuration object handed to a factory function.

The quick start shows it directly:

import { Chart, Title } from '@highcharts/react';
import { LineSeries } from '@highcharts/react/series/Line';
import { ColumnSeries } from '@highcharts/react/series/Column';
import { AreaSeries } from '@highcharts/react/series/Area';

export function Application() {
  return (
    <Chart>
      <Title>Chart with multiple series types</Title>
      <LineSeries data={[2, 4, 3, 1, 5]} name="Line series" color="red" />
      <ColumnSeries
        data={[3, 5, 1, 2, 4]}
        name="Column series"
        color="yellow"
      />
      <AreaSeries data={[4, 2, 1, 5, 3]} name="Area series" color="blue" />
    </Chart>
  );
}

Each series is a component with its own import path, so the type of each series is visible in the import rather than inferred from a string in a config blob. The `<Chart>` element is the parent, `<Title>` is a child, and the series elements are siblings of the title.

The stated reasons for this API are given in the feature list: a JSX-native API with clean syntax and patterns, support for all chart types from basic charts through Stock, Gantt and Maps, custom component integration without workarounds, full ES module support for tree shaking, a WebGL-powered Boost Module for rendering millions of data points, accessibility work, and zero external dependencies, with the library written from scratch.

The zero-dependency claim needs reading carefully, and it is about the wrapper only. The `package.json` declares `highcharts`, `react`, `react-dom` and `@types/react` as peer dependencies, and the installation note says those are installed automatically with npm v7 or later. So the wrapper itself pulls nothing in, but your application ends up carrying Highcharts, React and React DOM.

Peer dependencies define the compatibility envelope

The `package.json` is short and decisive about what versions work.

The package is `@highcharts/react` at version `5.4.0`, marked as an ES module with `"type": "module"`, with `main` pointing at `index.js` and `types` at `index.d.ts`. The build is a single command, `npx tsc`, and the only dev dependency is `typescript` at `^7.0.0`.

The peer dependencies set the floor. React, React DOM and the React types must be `>=18`, with `@types/react` marked optional in `peerDependenciesMeta`, and Highcharts itself must be `>=13.0.0`.

That Highcharts floor is the constraint most likely to surprise someone adopting this today. The wrapper is versioned independently of the charting library it wraps, so the two have to be compatible, and the peer range is the contract that says how.

The installation is the usual pair of commands:

npm install @highcharts/react

yarn add @highcharts/react

The note about peer dependencies being installed automatically with npm v7 or later is worth noting for teams on older npm, where the peer packages are not installed for you and you have to add them yourself.

The repository layout mirrors the Highcharts product structure, which is how the separate chart families are delivered. At the root there are `index.js` and `index.d.ts` for the main entry, and sibling bundles for the specialised products: `Highcharts.js`, `Stock.js`, `Gantt.js` and `Maps.js`, each with its own type declarations and source maps. There are also `series/` and `seriesModules/` directories for the per-series components, `options/` for the options-related components, `modules/` and `indicators/` for the extras, and `scripts/` for the tooling.

The container is a real DOM element you control

The chart renders inside a `<div>` container, and the library lets you pass props straight to it. The mechanism is a `containerProps` prop, and the documentation names the use cases: setting width and height, adding a `className`, attaching data attributes.

<Chart
  containerProps={{
    className: 'chart-shell',
    style: { width: '100%', height: '100%' }
  }}
>
  <Title>Full-width chart</Title>
  <Series data={[1, 2, 3]} />
</Chart>

This is a small feature with a disproportionate effect on how a chart behaves in a layout. Highcharts sizes itself to its container, and a chart in a flex or grid layout usually needs an explicit size or it collapses or overflows. Setting `style: { width: '100%', height: '100%' }` on the container, with a class for the surrounding CSS, is the difference between a chart that fills its panel and one that does not.

The `data attributes` mention is the other half. Because the props land on a real element in the DOM, the chart container can carry the identifiers that test selectors and analytics tooling look for, rather than those being bolted on afterwards around the chart element.

Nothing about the container is Highcharts-specific, which is the point. The wrapper does not own the layout; it hands you a div and lets you configure it like any other React element.

TypeScript support is built around three exported types

The TypeScript guidance is specific, and it steers you away from importing types directly from the Highcharts package.

For the `options` prop of the `Chart` component, you use `ChartOptions`, and the documentation says this is the recommended type over importing `Options` directly from Highcharts.

import { useState } from 'react';
import { Chart, type ChartOptions } from '@highcharts/react';

export function App() {
  const [options] = useState<ChartOptions>({
    series: [{ type: 'line', data: [1, 2, 3] }]
  });

  return <Chart options={options} />;
}

For a series component, you use `SeriesOptions<'line'>`, with the series type as the generic parameter, and the guidance is to match the generic to the `options` prop of the corresponding series component.

import { useState } from 'react';
import { Chart, type SeriesOptions } from '@highcharts/react';
import { LineSeries } from '@highcharts/react/series/Line';

And for the props of a series component itself, `SeriesProps` follows the same pattern and defaults to `'line'` when no generic parameter is given, with `SeriesProps<'pie'>` used for a different series component.

import type { SeriesProps } from '@highcharts/react';

const props: SeriesProps = {
  color: 'red'
};

So there are three type entry points, and the pattern is consistent: the generic parameter names the series type, and the default is `'line'`. The reason the library ships its own `ChartOptions` rather than telling you to import `Options` from Highcharts is that the wrapper's prop shape is not identical to the raw Highcharts option type, and the wrapper's version is the one that will not drift when the underlying library changes its own types.

For deeper typing questions, the repository points at a separate React TypeScript guide in the Highcharts documentation.

A Claude skill ships inside the package

One feature is unusual enough to be worth its own section, because it is a trend rather than a feature.

Highcharts React ships with a Claude skill to help you work properly with Highcharts in React projects. To add it to your `.claude/skills/` directory, the documentation gives a command:

node node_modules/@highcharts/react/scripts/highcharts-react-skill

The skill file itself lives at `node_modules/@highcharts/react/.claude/skills/highcharts-react/SKILL.md`, and the repository root has a `.claude/` directory of its own.

What this means practically is that a coding assistant working in your project can be given the vendor's own guidance on how to use the library correctly, rather than guessing at the API from the README. For a library with this many entry points and this many type names, that is a meaningful reduction in the ways an assistant can produce plausible but wrong code.

It is also a signal about where the vendor thinks the friction is. The skill exists because the JSX API has enough surface area that a model would otherwise write code against a different generation of the library. The same reasoning explains the emphasis on `ChartOptions` over the raw Highcharts `Options` type.

The `.claude/` directory at the repository root, alongside the `scripts/` directory that contains the installer, is the mechanism for this. It is worth knowing about if you use a coding assistant, and worth ignoring if you do not.

The licence is the commercial decision, not the wrapper's

This is the part to read carefully, and the repository is upfront about it.

The `package.json` declares the licence as `SEE LICENSE IN LICENSE`, and there are two licence files at the root, `LICENSE` and `LICENSE.txt`. The repository's licence is reported as a custom one that GitHub cannot classify.

The README's licence section says that getting licensed for commercial use makes you production-ready, with licence, updates and support for business-critical charts, and points to the Standard License Terms and the Annual Subscription terms on the Highcharts shop, along with a sales email address. The commercial support packages are described separately under Highcharts Advantage.

The distinction that matters is between the wrapper and the core. `@highcharts/react` is a thin integration layer, but Highcharts itself is the product with the commercial terms, and the wrapper's peer dependency on `highcharts` is where that obligation attaches. A team evaluating this needs to look at the Highcharts licence, not the wrapper's, and the README links to both.

The maintenance picture is otherwise healthy. The repository is not archived, the last push was on 2026-10-12, and there are no GitHub releases, with the `CHANGELOG.md` at the root carrying the version history instead. The version in the manifest is `5.4.0`, and the `Highcharts.js`, `Stock.js`, `Gantt.js` and `Maps.js` bundles with their type declarations and source maps are committed to the repository, which is what lets the package ship a `main` entry with prebuilt ES module output.

Support channels are the usual ones: GitHub, Stack Overflow, Discord and the Highcharts forums, with issues directed at the `highcharts/highcharts` working repository rather than this one.

Editorial conclusion

Highcharts React fits a React team that already uses Highcharts or wants its chart catalogue and accessibility work, and that wants charts declared in the same style as the rest of the component tree rather than assembled imperatively. It does not fit a project that needs a permissive licence, because the Highcharts core library carries its own commercial terms, and it does not fit a team on React 17 or earlier, since the peer dependencies require React 18 or later. Verify first that the `highcharts` version you install satisfies the `>=13.0.0` peer range, that the chart types you need are in the licence you are buying, because the repository ships separate entry points for Stock, Gantt and Maps, and that the zero-dependency claim covers the wrapper only, since the peer dependencies pull in Highcharts, React and React DOM.

Frequently asked questions

Official sources

1. highcharts/highcharts-react on GitHub
2. Issues
3. Project website
4. README