TradingView Lightweight Charts: a canvas charting library for financial data

What Lightweight Charts solves, and who it is for

The library exists for one narrow job: putting an interactive financial chart on a web page without paying for it in page weight. The README states the goal directly, describing the library as one of the smallest and fastest financial HTML5 charts and positioning it as a replacement for static image charts. That framing matters more than it sounds. A PNG of a candlestick chart costs nothing at runtime, but it cannot be panned, zoomed, crosshaired, or updated when new ticks arrive. Lightweight Charts gives you those interactions while keeping the payload close to that of an image, which is the trade the project is built around.

The audience is front-end and full-stack engineers working on trading interfaces, portfolio dashboards, crypto trackers, and internal analytics tools where the data is time series with open, high, low, close, and volume semantics. It is not aimed at people who want to drag rectangles on a chart to annotate a trade idea, and it is not aimed at people who need a general charting grammar for bar, pie, and scatter plots. The repository's own topics list names the domain explicitly: canvas, charting, financial-charting-library, html5-charts.

The package is written in TypeScript and ships typings, so the API is discoverable from an editor without reading the docs first. The declared runtime dependency set is one package, fancy-canvas, which is consistent with the size claims in the README. The published package version in the repository manifest is 5.2.1, matching the v5.2.1 release listed for 2026-08-12.

How the canvas rendering model works

Everything visible is drawn onto an HTML5 canvas element that createChart attaches to a container you pass in. You give the chart a width and a height at construction time, and you then add series to it. In v5 the README's example uses chart.addSeries(LineSeries), where LineSeries is imported from the package alongside createChart. Series objects own their own data: lineSeries.setData([...]) accepts an array of objects with a time and a value, and the example uses plain date strings such as '2019-04-11' for the time field.

That separation between the chart and its series is the core of the architecture. A chart is a container with layout options, scales, and interaction handling. A series is a data stream plus a renderer. The README points out that the built-in set of charting capabilities can be extended by building custom plugins, and it links a plugin catalog for ready-made ones plus a plugin-examples directory for writing your own. The plugin authoring skill in the repository draws a distinction between a custom series and a primitive, which tells you the extension surface is not a single hook but a choice between two levels of integration.

Because rendering happens on canvas rather than in the DOM, the library does not produce one element per data point. That is where the performance profile comes from, and it is also the reason the chart is opaque to the accessibility tree and to CSS selectors. If your application depends on inspecting or styling individual candles, the canvas model works against you.

The build output reflects this design. The package exports a production and a development ES module, plus standalone variants that bundle dependencies and expose a window.LightweightCharts global for script-tag usage. The manifest declares node >=22.3 in engines, which is a constraint on the build toolchain rather than on the browser runtime.

Installing Lightweight Charts from npm and rendering a first series

Installation is a single npm command. The README gives it without flags or peer dependency notes.

npm install lightweight-charts

If you want to try unreleased code from the default branch before a version is published, the README offers a pkg.pr.new build of master. Treat this as a preview channel rather than a version to pin in a product.

npm install https://pkg.pr.new/lightweight-charts@master

The import and usage are the same for both install paths. This is the README's own example, unchanged: it creates a chart sized 400 by 300 on document.body, adds a line series, and sets ten daily points.

import { createChart, LineSeries } from 'lightweight-charts';

const chart = createChart(document.body, { width: 400, height: 300 });
const lineSeries = chart.addSeries(LineSeries);
lineSeries.setData([
    { time: '2019-04-11', value: 80.01 },
    { time: '2019-04-12', value: 96.63 },
    { time: '2019-04-13', value: 76.64 },
]);

What you should see is a canvas appended to the body, with a line drawn through the three points and default axes. The width and height are fixed at creation, so a responsive layout needs the chart to be resized by your own code; the README's example does not cover that case.

There is also a CDN path for pages that do not use a bundler. The standalone production build is served from unpkg, and it creates a window.LightweightCharts object carrying all the exports of the ESM version.

const chart = LightweightCharts.createChart(document.body, { width: 400, height: 300 });
const lineSeries = chart.addSeries(LightweightCharts.LineSeries);

The README's build variant table is worth reading before you pick a file: production and development builds exist both with and without bundled dependencies, and only the standalone variants have an IIFE form for the window global. If you are wiring the library into a bundler, the package export map already routes development and production conditions to the right file, so importing the bare package name is enough.

For anyone using an AI coding assistant, the repository ships two Agent Skills that install with a single command. The README frames their purpose as supplying current v5 knowledge instead of snippets the assistant may recall from training.

npx skills add tradingview/lightweight-charts

Where Lightweight Charts is the wrong choice

The canvas rendering model is the source of its main limitation. Nothing in the chart is a DOM node, so there is no per-point element to attach a tooltip to, no CSS to restyle a single candle, and no built-in accessibility semantics for the plotted data. Applications that must expose chart values to screen readers, or that rely on DOM inspection for testing, will find the library fighting them rather than helping.

Drawing tools are a second gap. The related search phrases people use around this project include drawing tools and drawing, but the README describes a charting library with series, scales, markers, and plugins. Annotation and drawing workflows are the kind of thing the plugin system exists to support, not something the core promises. If your product's centerpiece is a user sketching trendlines on a chart, budget for plugin work or pick a product built around that interaction.

The library is also not a data layer. It renders arrays you hand it. There is no fetching, no caching, no websocket subscription, and no incremental update protocol beyond what the series API provides. Everything upstream of setData is your responsibility.

Finally, the attribution requirement is a real constraint rather than a footnote. The README states that the license requires specifying TradingView as the product creator, that you shall add the attribution notice from the NOTICE file and a link to tradingview.com to the page of your website or mobile application available to your users, and that the attributionLogo chart option can display an appropriate link. For a white-label product where every visible brand mark is negotiated, that is a design decision to make early, not after the UI is frozen.

Lightweight Charts compared with ECharts and Recharts

The honest comparison is about scope, not speed. ECharts is a general visualization library: it covers bar, pie, scatter, graph, geo, and candlestick among many series types, and it carries the configuration surface that breadth implies. Lightweight Charts covers financial time series and little else. If your dashboard mixes a candlestick panel with a pie chart and a sankey diagram, adopting Lightweight Charts means adopting a second library for the non-financial panels, and you should count that cost before you start.

Recharts takes a different architectural route entirely. It renders chart elements into the DOM through React components, which means your chart participates in the React tree, in CSS, and in whatever accessibility story your app already has. The price is element count: a dense financial series becomes a large number of nodes. Lightweight Charts inverts both properties. It is fast at high point counts and invisible to the DOM. Which one is correct depends entirely on whether your bottleneck is rendering cost or integration cost.

The related search phrases around this project include comparisons with plotly, highcharts, uplot, and TradingView itself. The TradingView comparison is a category error worth naming: the README describes this as a library for embedding a chart, while the full TradingView product is a hosted charting platform. The library is the piece you embed, not a substitute for the platform. Against uplot, the difference in approach is the same as against ECharts, a minimal canvas plotter versus a financial chart with a plugin extension model.

One more distinction: Lightweight Charts ships its own typings and is written in TypeScript. If you are working in a typed codebase, that removes a category of integration work that several of the alternatives require you to solve with community type packages.

Maintenance, versioning, and licence obligations

The repository is not archived, and the last push was on 2026-09-18. Releases in the listed history are v5.2.0 on 2026-04-24, v5.2.1 on 2026-08-12, and a plugin packages release on 2026-09-16, so the plugin packages are versioned separately from the core library. That separation is worth knowing before you pin dependencies: a plugin package can move on a different cadence than the chart itself.

Upgrade cost is dominated by the v5 API change. The README's own example uses chart.addSeries(LineSeries), and the repository ships Agent Skills whose stated purpose is to give assistants current v5 knowledge rather than outdated snippets. That is a strong signal that pre-v5 code, including the widely copied addLineSeries style, is a common source of breakage. If you are upgrading, the skill files are the cheapest place to read the current conventions.

Licensing is Apache-2.0, with a specific addition. The README states that the license requires specifying TradingView as the product creator, that you shall add the attribution notice from the NOTICE file and a link to tradingview.com to the page of your website or mobile application available to your users, and that the attributionLogo chart option can display an appropriate link. The README also notes that the software incorporates parts of tslib under the BSD Zero Clause License. Read the NOTICE file and the LICENSE in the repository for the exact wording; nothing here is legal advice, and the obligation is on the page your users see, not in a comment in your source tree.

Editorial conclusion

Adopt Lightweight Charts when the job is rendering price or indicator series in a browser and you want a small, typed, canvas-based library you can extend through plugins. Do not adopt it when you need a general-purpose statistical chart library, a server-side renderer, or a charting product you can rebrand without a visible TradingView link. Before shipping, check three things in the repository: the NOTICE file for the attribution wording, the v5 API surface in the documentation (addSeries, not the pre-v5 addLineSeries style), and the plugin catalog if your requirements go past the built-in series types. If you plan to write a plugin, start from the lightweight-charts-plugin-authoring skill rather than from a training-era snippet, because the plugin API is where most of the v5 breakage lives.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tradingview/lightweight-charts on GitHub