Stop Using System.Drawing: Modern Image Manipulation in .NET

If you've been a .NET developer for a while, you probably have a muscle memory for using System.Drawing whenever you need to resize a profile picture, generate a thumbnail, or stamp a watermark onto an image.

It used to be the default tool for the job. You’d write something like this without thinking twice:

// The old, deprecated way
using System.Drawing;
using var image = Image.FromFile("user.jpg");
// ... perform resizing logic ...
image.Save("user-thumb.jpg");

But if you’ve tried to deploy that code to a Linux Docker container or a Kubernetes cluster recently, you were probably greeted with a catastrophic application crash and a nasty PlatformNotSupportedException.

The .NET ecosystem has fundamentally shifted, and System.Drawing is no longer the cross-platform standard. Here is an exhaustive guide on why Microsoft killed it, what you should be using instead, and how to implement modern image manipulation pipelines in your C# applications.

Table of Contents

• 1. Why Did Microsoft Kill System.Drawing?
• 2. The King of Managed Images: SixLabors.ImageSharp
• 3. The High-Performance Alternative: SkiaSharp
• 4. The Heavyweight Champion: Magick.NET
• 5. The Future: Microsoft.Maui.Graphics
• 6. Which Library Should You Choose?
• Final Thoughts

1. Why Did Microsoft Kill System.Drawing?

To understand the shift, you have to understand the history of the API. System.Drawing was never originally designed for the modern web or serverless computing. It was fundamentally a managed wrapper around GDI+, an aging graphics API deeply integrated directly into the Windows operating system.

When Microsoft open-sourced .NET Core and pushed for cross-platform compatibility, they had a major problem: Linux and macOS do not have GDI+.

For years, the Mono project maintained a community-driven library called libgdiplus, which attempted to emulate Windows GDI+ behavior on Linux using Cairo. Microsoft relied on this for a while, but it was disastrous for production workloads. It was incredibly buggy, leaked memory constantly, and was a nightmare to maintain.

Finally, in .NET 6, Microsoft pulled the plug. They officially announced that System.Drawing.Common would only support Windows. If you attempt to execute it on a Linux server, it crashes by design.

If you are migrating legacy Framework apps or building new cloud-native microservices, you must choose a modern alternative.

2. The King of Managed Images: SixLabors.ImageSharp

If you need a robust, intuitive, fully managed, cross-platform image processing library, ImageSharp is arguably the gold standard in the .NET ecosystem.

Unlike older libraries, ImageSharp is written completely in C# from the ground up. It requires absolutely zero native dependencies. It runs perfectly inside Alpine Linux containers, AWS Lambdas, and anywhere else .NET runs, without requiring you to apt-get install any random C++ libraries.

Need to resize a user-uploaded avatar, crop it to a perfect square, and save it as a highly compressed WebP image? The API is beautifully fluent and modern:

using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Processing;
using SixLabors.ImageSharp.Formats.Webp;

// ✅ Remember to use async streams for optimal server performance!
public async Task ProcessAvatarAsync(Stream inputStream, string outputPath)
{
    // Load the image securely
    using var image = await Image.LoadAsync(inputStream);
    
    // Resize, keeping aspect ratio, cropping to a 200x200 square
    image.Mutate(x => x.Resize(new ResizeOptions
    {
        Size = new Size(200, 200),
        Mode = ResizeMode.Crop
    }));

    // Save as WebP with 80% quality for incredible bandwidth savings
    var encoder = new WebpEncoder { Quality = 80 };
    await image.SaveAsync(outputPath, encoder);
}

(Note: Always ensure you are following Async/Await Best Practices when dealing with heavy I/O streams like image uploading to prevent thread pool starvation).

The Catch: Licensing

ImageSharp is incredible, but it recently changed its licensing model. It is now dual-licensed. It is completely open-source and free for non-commercial projects or small businesses. However, if you are a commercial entity with over $1M in annual revenue, you are legally required to purchase a commercial license. For many enterprises, this is perfectly fine, but if you are a startup approaching that threshold, you need to be aware of the legalities.

3. The High-Performance Alternative: SkiaSharp

If your organization is balking at ImageSharp's licensing, or if you specifically require hardware-accelerated 2D graphics rendering (like drawing complex analytical charts, generating PDFs, or rendering custom typography), SkiaSharp is your best bet.

SkiaSharp is a .NET wrapper around Google's Skia Graphics Engine—the exact same high-performance C++ engine that powers Google Chrome, Android, and Flutter.

Because it relies on native code, it is blazingly fast. It is heavily utilized in high-throughput environments where .NET 8 Performance is critical.

using SkiaSharp;
using System.IO;

public void CreateRedSquare()
{
    // Create an in-memory canvas
    var info = new SKImageInfo(200, 200);
    using var surface = SKSurface.Create(info);
    var canvas = surface.Canvas;
    
    // Clear the background
    canvas.Clear(SKColors.White);

    // Draw a perfectly anti-aliased red square
    using var paint = new SKPaint
    {
        Color = SKColors.Red,
        IsAntialias = true,
        Style = SKPaintStyle.Fill
    };
    canvas.DrawRect(50, 50, 100, 100, paint);

    // Encode to PNG and save to disk
    using var image = surface.Snapshot();
    using var data = image.Encode(SKEncodedImageFormat.Png, 100);
    using var stream = File.OpenWrite("square.png");
    data.SaveTo(stream);
}

The Catch: Native Dependencies

Because SkiaSharp relies on native C++ binaries, you have to ensure the correct native assets are deployed alongside your application. On Windows, it usually "just works." However, if you are deploying to a Linux Docker container, you often have to run apt-get install libfontconfig1 in your Dockerfile to ensure the Skia engine can render system fonts properly.

4. The Heavyweight Champion: Magick.NET

If you are building an application that needs to support hundreds of obscure image formats (TIFF, PSD, SVG, RAW), or you need advanced Photoshop-level manipulation capabilities, Magick.NET is the answer.

Magick.NET is a C# wrapper for the legendary ImageMagick library. It is massive, incredibly powerful, and supports over 100 distinct image formats. If you need to convert a multi-page PDF into a series of JPEG thumbnails, Magick.NET can do it with a few lines of code.

The downside? The NuGet package size is significantly larger than the alternatives because it bundles massive native binaries, which will increase your Docker container sizes.

5. The Future: Microsoft.Maui.Graphics

It's worth mentioning that Microsoft is developing a new cross-platform graphics library called Microsoft.Maui.Graphics. Originally built for the MAUI UI framework, it provides an abstract, unified API for 2D drawing that can run on top of different rendering engines (like Skia on Linux/Android or Direct2D on Windows).

While it shows promise, it is primarily focused on UI rendering rather than backend server manipulation (like bulk image resizing on a web API). For pure server-side processing, ImageSharp or SkiaSharp remain the dominant choices.

6. Which Library Should You Choose?

• Choose ImageSharp if: You are building a standard ASP.NET Core web API that needs to resize user uploads, compress avatars, or crop thumbnails, and your company qualifies for the free license (or is willing to pay). It is the easiest to set up and deploy.
• Choose SkiaSharp if: You need raw performance, you are drawing complex geometric shapes or charts, or you need a completely free, MIT-licensed tool and don't mind managing Docker dependencies.
• Choose Magick.NET if: You are building a complex document management system that needs to process PDFs, PSDs, or other obscure enterprise file formats.

Final Thoughts

Holding onto System.Drawing in a modern, cloud-native world is a recipe for disaster. The .NET ecosystem has successfully transitioned away from Windows-only dependencies, and the modern alternatives are vastly superior in speed, safety, and API design to what we had a decade ago.

Pick the library that best fits your licensing needs and workload, update your Dockerfiles, and leave GDI+ in the past where it belongs.

Dealing with images in JSON APIs? If your frontend is sending images encoded as Base64 strings inside JSON payloads, stop writing console apps to debug them. Use my free Base64 Decoder/Encoder tool to instantly inspect, decode, and download the raw files securely in your browser!