# SixLabors.ImageSharp: a managed 2D graphics library for .NET, and the licence question that comes with it > ImageSharp handles image decoding, encoding and drawing entirely in managed C# for .NET 8, across device, cloud and embedded workloads. The library is capable; the Six Labors Split License is the part teams need to read before they ship. **SixLabors/ImageSharp** — A modern, cross-platform, 2D Graphics library for .NET - Repository: https://github.com/SixLabors/ImageSharp - Website: https://sixlabors.com/products/imagesharp/ - Stars: 8,035 · Forks: 900 - Language: C# - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/sixlabors-imagesharp ## What ImageSharp replaces, and for whom ImageSharp is a fully managed 2D graphics API for .NET. The README describes it as "high-performance, fully featured" and built for device, cloud, and embedded/IoT scenarios, and it is compiled against .NET 8. That combination is the pitch: no native binaries to ship alongside your application, no per-platform build matrix for the imaging layer. The practical audience is .NET teams that need to decode a JPEG, resize it, read its EXIF block, and write a WebP, all inside a process that might run on a Linux container, a Windows service, or an ARM device. The topics list on the repository covers bmp, gif, jpeg, png, tiff and webp, plus exif and drawing, so the format surface is broad rather than specialised. It is not a general graphics engine. There is no mention of vector rendering, shader pipelines, or video. If your problem is compositing a UI or animating a scene, this is the wrong layer. ## How the managed pipeline is structured The repository layout tells you most of the architecture: a single src/ tree, a tests/ tree, a shared-infrastructure submodule, and a solution file named ImageSharp.slnx. The README states the library is "designed from the ground up to balance performance, portability, and ease of use", and mentions that it exposes "low-level building blocks needed to extend the library for specialized workflows". That is the shape of the API: high-level entry points for common tasks, with lower-level primitives underneath for people writing custom processing. Because everything is managed C#, the same assembly runs on any supported .NET 8 target without a native shim, which is the main reason teams pick it over bindings to a C library. The cost of that choice is that performance work has to happen in C#. The README points contributors at "performance improvements" as a welcome contribution, which suggests the maintainers treat throughput as an ongoing effort rather than a finished property. The README does not publish benchmark numbers, and none should be assumed. ## Installing SixLabors.ImageSharp from NuGet The README gives NuGet as the installation route for stable releases, with development builds on a separate nightly feed. The package name is SixLabors.ImageSharp. The documented command is the standard dotnet add package form, run inside your project directory. ```bash dotnet add package SixLabors.ImageSharp ``` After the restore completes, the package reference appears in your .csproj and the SixLabors.ImageSharp namespace becomes available. The README does not pin a version in the installation table, so the version you get is whatever NuGet resolves as latest stable at the time you run it. If you would rather build from source, the README documents cloning the repository and then initialising submodules, since the project uses Git Submodules and Git Large File Storage. ```bash git clone https://github.com/SixLabors/ImageSharp git submodule update --init --recursive ``` The README also asks Windows users to enable long path support in Git before working with the repository, using a system-level config command. That is a development-environment step, not something your application needs. ## Where the documentation lives and what it does not cover The README points to detailed API documentation hosted on GitHub Pages, and to a separate Samples repository containing buildable code samples for common activities. It does not inline a getting-started example, and it does not document rollback, migration between major versions, or upgrade steps in the README itself. The repository does carry an AGENTS.md and a CLAUDE.md at the top level, alongside the usual CODE_OF_CONDUCT.md and SECURITY.md. Those filenames indicate guidance for AI coding assistants is part of the checked-in tree, which is a reasonable signal about how the project expects contributors to work. For questions, the README is explicit: use the Discussions forum, and do not open issues for questions. Feature ideas go to a separate Discussions category. If your team's habit is to file an issue when something is unclear, that habit will be redirected. ## The Six Labors Split License is the real adoption decision The repository's LICENSE file is the Six Labors Split License, Version 1.0, and the badge in the README reads "License: Six Labors Split". The repository metadata reports the licence as NOASSERTION, which means GitHub's classifier could not map it to a standard SPDX identifier. That mismatch alone is worth noting: automated licence scanners in a corporate pipeline may flag this project or, worse, silently pass it. The README links to a pricing page and to sponsorship options, and describes purchasing a commercial licence as a way to support development. Taken together, the split licence is a dual-licence arrangement with conditions attached to commercial use. The README does not restate those conditions, so the LICENSE file is the only place to read them. This is the single largest difference between ImageSharp and the permissive image libraries it competes with, and it is a business decision before it is a technical one. I cannot give legal advice, and this article does not. What I can say is that a team shipping a closed-source product should read the licence text and the pricing page before writing any code against the API, because retrofitting a licence decision after a release is expensive. ## ImageSharp vs SkiaSharp and System.Drawing The comparison people search for is ImageSharp against SkiaSharp, and the difference is architectural. SkiaSharp is a .NET binding over Skia, a native rendering engine, so it brings native binaries per platform and a rendering-oriented API. ImageSharp is fully managed C#, which the README frames as the portability argument, and its focus is image processing rather than a full rendering engine. Against System.Drawing, the split is different again. System.Drawing on .NET is a wrapper over platform graphics facilities, historically tied to Windows and GDI+. ImageSharp has no such dependency, which is why it appears in cross-platform and container workloads where System.Drawing is awkward or unsupported. A third option in the same space is Magick.NET, a binding to ImageMagick. That route gives you ImageMagick's very large format and operation catalogue, at the cost of native dependencies and an API surface shaped by a different language. None of these three is universally better; the managed-versus-native boundary and the licence are the two axes that decide it. ## Maintenance cadence and what upgrading costs The last push to the repository was on 2026-09-21, and the most recent releases are v4.1.2 on 2026-09-14, v4.1.1 on 2026-08-20, and v4.1.0 on 2026-08-11. That is a tight patch cadence inside the 4.1 line, with a minor release roughly a month before the latest patch. The repository is not archived. What the README does not show is a migration guide between major versions. It documents installation and building from source, and points to external documentation, but it says nothing about breaking changes or upgrade paths. If you are on an earlier major version, plan to read the release notes and the API documentation rather than expecting the README to carry you. The repository also uses submodules and Git LFS, which matters if you vendor the source or build it in CI. A shallow clone that skips submodule initialisation will not build. The README's own instructions include the submodule command for exactly that reason. ## Conclusion Adopt ImageSharp if you are on .NET 8 and want image decode, encode, resize and drawing without native dependencies, and if the Six Labors Split License terms fit how you distribute the software. Do not adopt it if you need a permissive licence with no commercial condition, or if you need SVG, video or a GPU rendering pipeline. Before committing, verify the current licence text in the LICENSE file and confirm which usage tier your product falls into. ## FAQ ### Is SixLabors.ImageSharp free? It is licensed under the Six Labors Split License, Version 1.0, which the README links to in the LICENSE file. The README also links to a commercial licence purchase page and to sponsorship options, so the licence is split rather than a single permissive grant. Read the LICENSE text to determine which side applies to your use. ### What is SixLabors.ImageSharp? It is a fully managed, cross-platform 2D graphics API for .NET, described in the README as a high-performance image processing and graphics library built for device, cloud, and embedded/IoT scenarios. It is compiled against .NET 8 and covers formats including bmp, gif, jpeg, png, tiff and webp, plus exif and drawing. ### Is ImageSharp free for commercial use? The README does not state the commercial-use terms directly. It identifies the licence as the Six Labors Split License, Version 1.0, links to the LICENSE file, and links to a pricing page for commercial licences. The conditions are in the licence text, not the README. ### How does ImageSharp compare with SkiaSharp? ImageSharp is fully managed C# built against .NET 8, which the README presents as the portability argument, and it targets image processing and drawing. SkiaSharp is a binding over the native Skia rendering engine, so it carries native binaries and a rendering-oriented API. The README does not benchmark the two against each other. ### Is ImageSharp open source? The source is publicly available on GitHub under the Six Labors Split License, and the README invites contributions to algorithms, performance improvements and unit tests. The licence is a split licence rather than a single permissive one, and GitHub reports it as NOASSERTION. ### What is a good C# library for image processing? ImageSharp is a fully managed option built against .NET 8 that covers bmp, gif, jpeg, png, tiff and webp along with exif and drawing. The README also points to a Samples repository with buildable examples, which is the fastest way to judge whether its API fits your workload. ## Sources - [Issues](https://github.com/SixLabors/ImageSharp/issues) - [Project website](https://sixlabors.com/products/imagesharp/) - [README](https://github.com/SixLabors/ImageSharp/blob/main/README.md) - [Releases](https://github.com/SixLabors/ImageSharp/releases) - [SixLabors/ImageSharp on GitHub](https://github.com/SixLabors/ImageSharp) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sixlabors-imagesharp