OxyPlot: a .NET plotting library that keeps charts out of your UI framework

What OxyPlot is for, and who ends up using it

OxyPlot is a cross-platform plotting library for .NET. The problem it addresses is the one that shows up when chart code gets welded to a particular UI toolkit: you write a charting component inside a WPF window, then need the same plot in a different host, and the drawing logic has to be pulled apart. OxyPlot's answer is to separate the chart description from the thing that paints it. The README's getting-started list is four steps long, and three of them are about that separation: add a NuGet reference, add a PlotView to your user interface, create a PlotModel in code, and bind the PlotModel to the Model property of the PlotView.

The audience follows from that shape. If you are building a desktop .NET application with WPF, you are the primary reader, and the related searches around OxyPlot WPF reflect that. But the library is not WPF-only: the repository topics list c-sharp, charts, dotnet, netcore, netstandard, plot-library, plotting and wpf, and netstandard and netcore in that list are the signal that the core is not tied to one framework. Teams that generate plots for reports, dashboards or scientific output and want the same PlotModel to survive a UI change are the ones who get the most out of this design.

PlotModel, PlotView and the data flow between them

The mechanism is a model-view split, and it is worth being precise about which side owns what. A PlotModel is a plain object graph: series, axes, annotations, titles, legends. A PlotView is the UI element that displays it. The binding in step four of the README is the whole contract. You construct the model, hand it to the view through the Model property, and the view renders it.

That has a practical consequence. Anything you can express as a PlotModel can be rendered by any view implementation that understands the model, which is why the library can claim cross-platform support while the README's own example path stays on WPF. The examples live in the /Source/Examples folder of the repository, and that folder is the honest documentation of what the model can express; the README does not enumerate series types or axis options, and the readthedocs site and the wiki carry the rest.

The cost of this split is indirection. When something looks wrong on screen, the fault is either in the model or in the view, and you have to decide which. A library that draws directly into a control collapses that question. OxyPlot does not, and that is a deliberate trade rather than an oversight.

Installing OxyPlot and binding a first PlotModel in WPF

The README gives the install as a NuGet reference and points at the wiki page on NuGet packages for the list of what is available. The stable releases are published to nuget.org, and the README notes that the feed also carries many old v2015.* and pre-release packages that sometimes surface even when unlisted. Search for the package that matches your UI framework rather than installing the first result.

Once the reference is in place, the code follows the README's four steps: a PlotModel is created in your code and bound to the Model property of a PlotView added to your user interface. The README does not print a code sample of its own, so the examples to copy are the ones in the /Source/Examples folder of the repository. What you should see after the binding is a plot area inside your window; if it stays empty, the model you bound is the first thing to inspect.

For pre-release builds the README gives a different route: set the myget.org package source to https://www.myget.org/F/oxyplot and remember the "-pre" flag. The exact package identifier for your target framework is the thing to confirm on the wiki page before adding the reference.

Where OxyPlot gets awkward

The documentation is split across three places: the README, a readthedocs site, and a GitHub wiki. The README itself is short and defers almost everything, including the NuGet package list, to the wiki. That is a real cost for a newcomer. You cannot read one page and know which package to install; you follow a link, and then another.

The release cadence is the second thing to weigh. v2.2.0 was released on 2024-09-20, following v2.1.2 on 2022-12-03 and v2.1.0 on 2021-10-04. The gaps between those tags are measured in years, not months. The develop branch was pushed on 2026-07-30, so work continues, but a fix or a feature you need may sit unreleased for a long time. If your project depends on a behaviour that only exists on develop, you are building against a branch, not a version.

Third, the library assumes you are comfortable writing chart definitions in C#. There is no designer, and the README offers no configuration-file route. If your team's workflow is to lay out charts visually, OxyPlot will feel like the wrong shape entirely.

OxyPlot against ScottPlot

The comparison that comes up in search is OxyPlot versus ScottPlot, and the difference is architectural rather than cosmetic. OxyPlot's centre of gravity is the PlotModel and the binding to a view, which is what makes the same chart definition portable across UI frameworks. A control-first library puts the plotting surface itself at the centre, so you interact with the control rather than with a model object.

That distinction decides which one you want. If you are writing a WPF application and want to build chart state in a view model, test it without a UI, and bind it, OxyPlot's model-first design is the closer fit. If you want to drop a control onto a form and call plotting methods on it, the control-first approach is more direct. Neither is a quality judgement; they are different bets about where the complexity should live. The README's four-step list is a fair summary of OxyPlot's side of that bet.

Licence, maintenance and the cost of upgrading

OxyPlot is MIT licensed. For most consumers that means the obligation is limited to preserving the copyright notice and licence text, but the repository's LICENSE file is the authority and this is not legal advice.

Upgrade cost is driven by the release spacing. Moving from v2.1.x to v2.2.0 spans roughly two years of accumulated changes, so a jump across that boundary is likely to surface API differences that a series of small upgrades would have spread out. The CHANGELOG.md at the repository root is where those changes are recorded, and it is the file to read before bumping the package reference. The GitVersion.yml file at the root indicates that version numbers are produced by GitVersion, which matters if you build the library from source rather than consuming NuGet packages: your local build will derive its version from the branch, not from a hand-edited number.

The repository is not archived, and the last push to develop was on 2026-07-30. That is evidence of ongoing work on the branch. It is not evidence that a release is imminent, and the tag history above is the reason to keep those two things separate.

Editorial conclusion

OxyPlot fits .NET teams that want a chart model they can bind to a PlotView in WPF or another supported UI, and that can live with documentation spread across a readthedocs site and a GitHub wiki. Do not pick it if you need a charting control with a designer surface or a vendor support contract; the project is a library, not a product, and the README points contributors at .github/CONTRIBUTING.md rather than at a support desk. Before committing, check the NuGet feed for the package matching your UI framework, because the README warns that old v2015.* and pre-release packages appear on nuget.org even when unlisted, and confirm the API you need exists in the v2.2.0 line rather than in an example from /Source/Examples.

Frequently asked questions

Official sources

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