SVG.NET: a .NET library for reading, writing and rendering SVG 1.1

Reading, writing and rendering SVG from managed code

SVG.NET is a C# library to read, write and render SVG 1.1 images in applications based on the .NET framework.

Those three verbs are the scope, and each one implies a different use. Reading is the obvious case: pulling an existing vector asset into a desktop application, parsing the document into an object model, and querying or modifying its elements. Writing is generating an SVG, which is what a charting or diagramming tool needs. Rendering is turning that document into pixels, which is the one with the sharp edges.

The library is compatible with platforms implementing .NET Standard 2.0 and works under Windows, Linux and macOS, and the README qualifies that last claim: the latter two with some limitations with respect to rendering. That parenthetical is doing real work, and it is the single most important line in the README for anyone deploying on macOS or Linux. The parsing and the object model are portable, since they are pure managed code, but the rendering path depends on what the platform provides, and on the two non-Windows platforms something is missing or different.

The intended user is a .NET developer building a desktop or server application that has to deal with SVG as data rather than as an asset. The topics confirm the shape of the library: `svg`, `vector-graphics`, `dom`, `css`, `c-sharp` and `nuget`. The `dom` topic is the giveaway, because SVG is an XML document with a document object model, and this library implements that model in C#.

The primary language is C#, the default branch is `master`, the last push was on 2026-07-22, and the repository has no GitHub releases, so the NuGet package and the documentation site are the practical artefacts.

From CodePlex to vvvv to the svg-net organisation

The history section is unusually detailed, and it explains a lot about the shape of the codebase.

The project is a public fork of the SVG.NET C# library originally created by Microsoft on CodePlex, which is now defunct. It started out as a private fork by the company vvvv, with some minor modification to enable the writing of proper SVG strings. After almost two years of fixes and improvements the company decided to share the codebase with the public in order to improve it even further. And in 2021, the repository was transferred from the company organisation to the new svg-net organisation, SVG.NET.

Three things follow from that history. The first is the origin of the code quality, since a lot of it was written by one company for one product, which means the API reflects the needs of a live creative tool rather than a general purpose library design. The second is the longevity, because a library that a commercial product has depended on for years gets maintained in a way that a hobby project does not. The third is the age of the code, since the base is a Microsoft library from the CodePlex era, and a codebase of that vintage accumulates the kind of layering that a modern rewrite would avoid.

The list of projects using the library is the best evidence of the second point. It includes vvvv itself, a hybrid visual and textual live-programming environment for prototyping and development, Posh, a windowing, interaction and drawing layer for C# and .NET desktop applications with the GUI in a browser, Timeliner, a Posh based timeline controlled by and sending values via OSC, Chordious, a fretboard diagram generator for fretted stringed instruments, HttpMaster, a Windows tool for HTTP testing and debugging, and Mappalachia, a Windows tool for generating maps of the game Fallout 76.

Those are desktop and creative tools with real users, and Chordious in particular is a good example of the shape of use: a fretboard diagram generator produces SVG output that has to be correct, and the writing of proper SVG strings, which was the original modification that started the fork, is exactly the capability such a tool needs.

The MS-PL licence and the one dependency

The licence is MS-PL, the Microsoft Public License, and the README notes that the project has dependencies on other open-source projects, referenced via NuGet packages and potentially subject to different licences.

There is one such dependency, and it is tabulated. ExCSS, by Tyler Brinks, from GitHub, under the MIT licence.

The presence of a CSS parser is not incidental to the design. SVG carries presentation through style attributes and through `<style>` elements with CSS rules, and an SVG implementation that ignores the stylesheet has a broken idea of what the document looks like. ExCSS is what lets the library resolve those rules, which is why the licence table lists it explicitly and why a fork that has to keep the style handling correct has a hard dependency on somebody else's CSS implementation.

The MS-PL itself is a Microsoft permissive licence derived from the Ms-PL, which grants broad rights to use, modify and redistribute with a notice requirement. For a library that many projects depend on, that is a workable arrangement, and it is a departure from the MIT or Apache terms that most current .NET packages use, so a distribution review has to cover it rather than assume.

The same caution applies to the dependency list. The README warns that the referenced projects are subject to different licences, and in this case the ExCSS licence is MIT, which is the permissive end. So the combination here is permissive throughout, but it took an explicit table to say so, and that table is a good model for what a library with dependencies should publish.

The samples are the better documentation

The README is candid about its own documentation. It points to the documentation pages for installation and usage information and for release notes, and then says that the documentation is very rudimentory and that any help to improve it is greatly appreciated.

That sentence tells a reader where the real information is, and the repository answers it. The `Samples/` directory contains `Entities/`, `SVGBuilder/`, `SVGViewer/`, `SvgConsole/` and `SvgRuntimeUpdates/`, and the names describe five distinct things you might want from an SVG library: working with the object model, building a document, viewing one, driving it from a console, and updating it while it runs.

`SvgRuntimeUpdates` is the interesting one, because it addresses a case that static SVG handling does not. A document that is being edited in a viewer needs to change, and a library that only parses a file at load time will not support that. The `SVGViewer` sample and the runtime updates sample together suggest the library is intended for live editing rather than only for batch conversion.

The `Generators/` directory at the root of the repository is another structural hint, and the contribution notes explain the context. The project is in need of contributors, and assistance in areas such as code reviews and testing is particularly needed. For those interested in leading or contributing to specific initiatives like the codebase segmentation, the project asks to be contacted. Segmentation of the codebase is a refactoring initiative that usually means the library has grown past a single assembly, which is consistent with a codebase that began as one company's internal copy of a Microsoft project and has been extended by several consumers since.

The `Docs/` directory and the `Tests/` directory sit alongside `Source/`, and the README badges show both a Testsuite workflow and a DocBuild workflow on the `master` branch, so the tests and the documentation are built in CI rather than assembled by hand.

Maintenance state and what the version history does and does not tell you

The repository has no GitHub releases, and the last push was on 2026-07-22, which is more than three months before today. The NuGet package is where a user gets a released version, and the documentation site carries the release notes, which the README explicitly directs you to for that purpose.

What the repository shows is the shape of the project rather than its release cadence. The testsuite and documentation build badges are on the `master` branch, so CI runs on the branch people clone. The `main` branch is not mentioned anywhere in the README, which suggests the default branch is the working branch, which is a pattern in long-lived community-maintained libraries where the default branch is a moving target and the tagged NuGet release is the stable artefact.

The absence of tagged releases in the repository is consistent with that. A user pins a NuGet version, and the repository's commit history is where the changes are read.

The most important maintenance fact is the one the README states outright: the project is in need of contributors, and code review and testing help are particularly needed. For an authentication-adjacent or graphics-adjacent library that a handful of companies depend on, that is a real signal about the risk profile, and it is a signal the maintainers have chosen to publish rather than hide.

The documentation gap compounds it. When the prose is thin, the samples and the tests become the specification, and a contributor who is not the original author has to reconstruct intent from a codebase that came out of a defunct CodePlex project and then a private company fork.

Where SVG.NET is the wrong tool

There are three cases where this library does not fit, and the first is by far the most common.

The first is a browser application. If your code runs in a browser, the platform already gives you a complete SVG implementation through the DOM, with rendering, styling, animation and event handling, at no dependency cost and with no cross platform caveats. Pulling a .NET SVG library into that stack means shipping a runtime and reimplementing what the browser already does.

The second is a rasterisation requirement on Linux or macOS. The README's own qualification, some limitations with respect to rendering, is the whole story here. If your pipeline is: generate an SVG, then rasterise it to PNG for a report, and you are on macOS, then this library's rendering path is the part that is least likely to behave the way you expect, and the fallback is another tool in the pipeline.

The third is a modern .NET application that needs SVG support from a maintained ecosystem. The base code is a Microsoft library from the CodePlex era, and the surrounding work of updating it is carried by a small volunteer group. A team that wants a supported dependency with a service level would be better served by a different library, and the difference in approach is between a library with a long history of use in production tools and one with an active upstream and a support commitment.

For the cases it does fit, the value is specific. SVG.NET can produce proper SVG strings, which is the modification that started the whole fork, and it has been doing that inside a live coding environment for years. A .NET developer who needs an SVG object model, an SVG writer and a renderer on Windows, and who is comfortable contributing fixes upstream, is exactly the user this repository is for.

Editorial conclusion

Adopt SVG.NET if your .NET application needs to read an existing SVG, generate one, or rasterise one, and you are on .NET Standard 2.0 or later, because the library has been in production use inside vvvv and its related tools for years. Do not adopt it for a browser side application that already has the DOM, where the platform's own SVG support is free, and treat the rendering caveat on Linux and macOS as a real constraint rather than a footnote. Verify three things first: that the rendering you need works on the platform you deploy to, because the README notes limitations with respect to rendering on Linux and macOS, that the MS-PL terms and the MIT terms of the ExCSS dependency are both acceptable for your distribution, and how much of the API you actually use, since the documentation pages are described as very rudimentory and the samples are the better guide.

Frequently asked questions

Official sources

1. Issues
2. License: MS-PL
3. Project website
4. README
5. svg-net/SVG on GitHub