Svg.Skia: reading SVG through a scene graph into SkiaSharp

The NuGet table is the real API surface of Svg.Skia

The most telling part of this README is not a description of the library but a table of packages. It lists more than twenty rows, starting with ShimSkiaSharp and Svg.Model, then Svg.SceneGraph, Svg.Skia itself, Svg.Skia.Converter, Svg.Skia.JavaScript and Svg.SourceGenerator.Skia, followed by Svg.Custom, Svg.Animation, SvgML.Avalonia and SvgML.Maui. The editor stack appears as Svg.Editor.Core, Svg.Editor.Svg, Svg.Editor.Skia, Svg.Editor.Avalonia and Svg.Editor.Skia.Avalonia, and the view layer as Svg.Controls.Avalonia, Svg.Controls.Skia.Avalonia, Svg.Controls.Skia.Maui and Svg.Controls.Skia.Uno.

That spread tells you the design intent: one parsing and geometry core shared by several host frameworks, with an editing stack and a code generator built on top of it. It also tells you the adoption cost. A team that only wants to draw an SVG in a desktop app can end up referencing half a dozen packages, and the naming does not make the dependency order obvious at a glance. Svg.Skia.Converter and Svg.Skia.JavaScript exist as separate packages rather than options on the core one, which keeps the core lean but pushes the choice onto you.

The sample tree shows how the pieces are meant to be combined

The samples directory is the closest thing to usage documentation in this repository, and it is worth reading as a map. There are paired projects for Avalonia and MAUI that render plain SVG (samples/AvaloniaSvgSample, samples/MauiSvgSkiaSample) and paired projects that go through Skia (samples/AvaloniaSvgSkiaSample, samples/AvaloniaSvgSkiaStylingSample). An Uno set exists in samples/UnoSvgSkiaSample and samples/UnoTestApp, and an Avalonia sample renders a recorded Skia picture (samples/AvaloniaSKPictureImageSample).

Two samples target tooling rather than end users: samples/Svg.Skia.Converter for the converter package and samples/Svg.SourceGenerator.Skia.Sample for the source generator. A rasterisation path sits in samples/SvgToPng, and a command line style project lives in samples/svgc, which pairs naturally with samples/AvalonDraw for drawing output.

The duplication across Avalonia, MAUI and Uno is the point of the control packages, and it is also the maintenance signal. Three host frameworks means three sample apps and three control packages to keep in step with every Skia or Avalonia upgrade.

Getting Svg.Skia: NuGet packages and a MyGet nightly feed, with no install command

There is no install command in the README. The project points you at package registries instead, and the core package appears in the table with its NuGet link in the format shown below.

| `Svg.Skia` | [![NuGet](https://img.shields.io/nuget/v/Svg.Skia.svg)](https://www.nuget.org/packages/Svg.Skia/) | [![NuGet Downloads](https://img.shields.io/nuget/dt/Svg.Skia.svg)](https://www.nuget.org/packages/Svg.Skia/) |

The badge block above the table points to the main NuGet package and to a MyGet feed carrying nightly builds of the same package set. The nightly feed matters for one specific reason: if you track a recent SkiaSharp or Avalonia preview, the stable package may not be the one you want, and the README gives you a place to look rather than a set of instructions. Everything else you need is a package reference in your project file, chosen from that table. The absence of a documented command line install step is a small annoyance, not a blocker, but it does mean the first hour of any evaluation is spent matching rows in a table to the framework you actually target.

A script driven build with Nuke, a slnx solution and pinned package versions

The repository root shows a build setup that expects command line work rather than a click in an IDE. There is a .nuke directory, which is the conventional layout for NUKE build automation, alongside build.sh, build.ps1 and build.cmd entry points, so the same build runs from a Unix shell, from PowerShell and from a Windows command prompt. The solution file is Svg.Skia.slnx, the newer XML based solution format, and the root also holds Directory.Build.props and Directory.Packages.props, which is how the project pins its central package versions in one place rather than scattered across project files.

Two more root files shape the build. NuGet.Config controls which feeds are consulted, which matters if you consume the MyGet nightlies alongside public NuGet. global.json pins the .NET SDK version the build expects, so a machine with a different SDK installed will be corrected rather than silently used. The docs pipeline has its own scripts, build-docs.sh and build-docs.ps1, alongside serve-docs.sh and serve-docs.ps1 and a check-docs pair, so publishing the site is separated from compiling the library.

For a reviewer this is a plus. The dependency graph is centralised in Directory.Packages.props, which is exactly the file to inspect when you want to know which SkiaSharp and Avalonia versions a given release actually binds to.

Documentation lives in a docs folder and a hosted site, not in the README

The README is deliberately thin. It carries badges for CI, the NuGet packages, the MyGet feed and the GitHub releases, then the package table. Everything explanatory is elsewhere in the tree: a docs directory, a site directory with a _config.yml for GitHub Pages, and a published homepage at the project site. The build scripts named earlier exist to produce that site.

A working notes file at the root, PR_SUMMARY_resvg_resource_parity_performance.md, names its own subject: resource parity against resvg and the performance work that followed. Its presence tells you the project compares itself to a native renderer and tracks parity explicitly. It does not tell you the current state of that effort, so treat the file name as a pointer to the work rather than as a claim about coverage.

Other root files set expectations for a working relationship with the project. SECURITY.md defines how vulnerabilities get reported, CHANGELOG.md records releases, AGENTS.md describes the working rules for contributors, and plan holds planning notes. A tests directory and a separate tests-sourcegenerators directory exist, so the source generator is tested apart from the renderer.

What the README leaves unanswered about usage and compatibility

Three practical gaps are worth naming before you adopt this library. First, no API usage snippet appears anywhere in the README, so learning the entry points means reading the samples or the hosted documentation. Second, the README publishes no compatibility matrix between Svg.Skia releases and SkiaSharp or Avalonia versions, which is where most upgrade friction in this ecosystem actually lives. Third, there is no rollback procedure documented.

None of these are fatal, and all three are checkable. Open the samples for your target framework and read the code rather than the README. Open Directory.Packages.props to see which versions the current release binds to, and compare them with what your application already references. Read CHANGELOG.md to see how far the 5.2.x line has moved since v5.2.1.

One structural limit deserves emphasis. Because the parser, the scene graph, the controls and the editors are separate packages, upgrading only some of them is possible, and nothing in the README prevents a mismatched combination. Central package management in the repository helps the maintainer, but your own project file is where the consistent set has to be enforced.

Svg.Skia against a hand written SkiaSharp pipeline

The alternative to adopting this library is to build the pipeline yourself: pick an SVG parser, walk the document tree, convert paths and transforms into Skia objects and push them to a canvas. The approach is legitimate for a narrow requirement, especially when you need exactly one feature such as path conversion to geometry and nothing else.

What that approach costs is the part Svg.Skia has already assembled. The repository contains separate packages for a model layer, a scene graph and a converter, so the usual starting point is the model plus the scene graph, with the renderer layer sitting above them. The control packages exist so that the same vector content can be hosted in Avalonia, MAUI or Uno without each team writing its own control, and the editor packages add an interactive editing layer rather than read only display.

The trade-off is explicit. A hand written pipeline for a single conversion keeps your dependency list to a parser and SkiaSharp itself. Svg.Skia gives you a scene graph, cross framework controls, an editor and a source generator in exchange for a wider package set and a learning curve that starts in the samples.

Maintenance pace in August 2026 and the cost of the 5.x line

The repository is not archived, and the last push was on 2026-08-27. Three releases sit inside the same month: v5.2.1 on 2026-08-12, v5.2.2 on 2026-08-25 and v5.2.3 on 2026-08-27. The project is under active development, and the cadence suggests a library that responds to upstream Skia or Avalonia moves rather than one on a fixed schedule.

That responsiveness has a cost for consumers. Patch releases within a 5.2 line are cheap to take, but the fact that a 5.x major version is current means the API surface has already moved through major revisions, and your code may need adjusting when you move across those lines. The many package structure means each of those packages versioned and shipped together, so a single upgrade can touch several references in your project file.

Licensing is the simplest part of the decision. The repository carries an MIT licence, which permits commercial use, modification and redistribution, including inside closed source applications, with the notice retained. That is a permissive choice with no copyleft obligation, though your organisation still needs to confirm that the licence of SkiaSharp and Avalonia aligns with its own use.

Editorial conclusion

Adopt Svg.Skia when your C# application must display or edit SVG inside Avalonia, MAUI or Uno and you would rather not hand-roll parsing plus a scene graph plus Skia rendering. Skip it if you only need to rasterise a handful of files, since the dependency surface is far wider than the core package. Before committing, check that the current 5.2.x packages resolve against your Avalonia and SkiaSharp versions, because no compatibility matrix is published, and confirm that the sample applications in the repository cover the target framework you intend to ship.

Frequently asked questions

Official sources

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