Plotly.NET: type-safe charts for .NET, built on plotly.js

Several API layers over one chart object

Plotly.NET is an Interactive charting library for .NET programming languages, built on top of plotly.js, providing several API layers for creating, styling and rendering data visualisations. The layering runs from a high-level, type-safe Chart API down to low-level direct chart object manipulation, and the core API is written in F#. That is the key fact about the design, and there is an F1000Research paper linked for a deep dive into the rationale behind the choices. The layers exist because different callers want different amounts of control: a person plotting ten points wants the short form, and a person building a chart configuration UI wants to manipulate the object graph directly. A library that exposed only one of those would make one of the two groups work around it.

Four packages and what each is for

The packages are the practical picture. Plotly.NET is the core API, written in F#, providing the multiple API layers to create and style charts, and it is the foundation for all the others. Plotly.NET.Interactive provides interactive formatting extensions for .NET interactive notebooks. Plotly.NET.ImageExport provides extensions for rendering charts as static images programmatically. Plotly.NET.CSharp provides an idiomatic C# API, and the README is careful about what that means: you can use the core API in C#, this package just removes some friction at some places. All four are on NuGet. So the choice for a C# project is between adding the C# package for convenience or the core package and living with the F# shaped API.

F# quick start in a script and a notebook

In an F# project you add the Plotly.NET package and you are ready to go. In a .fsx script you reference the package with a nuget directive.

#r "nuget: Plotly.NET"

Then you build a chart with a pipeline.

open Plotly.NET

Chart.Point(
    x = [0 .. 10],
    y = [0 .. 10]
)
|> Chart.withTitle "Hello World!"
|> Chart.show

In a polyglot notebook you reference the Interactive package instead, and you display the chart by ending a cell with it rather than calling show.

#r "nuget: Plotly.NET.Interactive"

The difference between the two forms is the rendering step. Chart.show writes the chart out and opens it in a browser, while the notebook integration renders in place, which is why the notebook path needs a different package.

The C# path and why a separate package exists

In a C# project you add the Plotly.NET.CSharp package. In a polyglot notebook for C# you reference both the Interactive and the CSharp packages.

#r "nuget: Plotly.NET.Interactive"
#r "nuget: Plotly.NET.CSharp"

The chart call itself is generic over the axis and label types.

using Plotly.NET.CSharp;

Chart.Point<int, int, string>(
    x: Enumerable.Range(0,11),
    y: Enumerable.Range(0,11)
)

The three type parameters are the interesting part, because they are the whole reason the C# package is worth having. The F# core infers its types from the pipeline, while a C# caller has no such inference, so the types have to be stated. A separate package for that is a small thing, but it is the difference between a C# developer fighting generic inference and one writing three type arguments.

The build scripts and the release chain

The build directory holds the targets, and the README shows the two entry points. On Windows there is build.cmd, on Linux and macOS build.sh, and each takes a target.

# Windows

# Build only
./build.cmd

# Full release buildchain: build, test, pack, build the docs, push a git tag, publish the nuget package, release the docs
./build.cmd release

# The same for prerelease versions:
./build.cmd prerelease


# Linux/mac

# Build only
build.sh

# Full release buildchain: build, test, pack, build the docs, push a git tag, publísh the nuget package, release the docs
build.sh release

# The same for prerelease versions:
build.sh prerelease

The release chain is the useful part of that list, because it shows the order of operations: build, test, pack, build the docs, push a git tag, publish the NuGet package and release the docs. Note that the release and prerelease targets assume there is a NUGET_KEY environment variable containing a valid NuGet.org API key. The docs have their own watch target for local development with hot reload.

Documentation generated from the source

The samples and tutorials live at plotly.github.io/Plotly.NET and the API reference for all packages at the reference index on the same site. The mechanism behind them is stated clearly: the documentation for this library is automatically generated, using FSharp.Formatting, from fsx and md files in the docs folder, and the README invites you to submit a pull request if you find a typo. So the documentation is in the repository rather than in a separate system, which is the arrangement that keeps the samples and the code from drifting. The repository layout reflects that, with a docs directory, a build directory, src, tests, tools, a publication directory, plans and a devcontainer, plus three solution files: Plotly.NET.sln, Plotly.NET.Core.sln and Plotly.NET.TestSuite.sln.

Where Plotly.NET is the wrong choice

Four limits apply. The charts are rendered by plotly.js, so a .NET application that needs a chart embedded in a native desktop control has a problem the library does not solve, and the ImageExport package is the answer for static images rather than for interactivity. The library is F# first, so a C# team is either using the convenience package and losing some of the F# shaped API, or reading F# code. It depends on the browser, which means the chart output is HTML and JavaScript rather than a drawing object you own. And the version story is unsettled: the badge shows support for plotly.js version 2.27.1, the latest release is 5.1.0 from 2024-09-04, there is a 6.0.0 preview from 2025-07-28, and the last push to the repository was on 2026-09-10, so the stable line and the working line are some distance apart.

Editorial conclusion

Use Plotly.NET when you want the plotly.js chart vocabulary from .NET without hand-writing the JSON for every trace, since the typed API keeps the chart object shape in F# or C# types. Do not expect a managed renderer, because the charts are rendered by plotly.js in a browser and the image export package is what covers the static case. Verify first which package you actually need, since the core is F# and the C# package exists to remove friction rather than to replace it, that the plotly.js version you bundle matches the one the library was built against, and that the interactive notebook package is the one you want if you are working in a polyglot notebook rather than a console application.

Frequently asked questions

Official sources

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