ImageResizer 5: on-demand image processing for .NET Framework, with a split licence

The query string is the whole API

ImageResizer is a library for .NET Framework that performs image resizing, compression and manipulation on demand, driven by the URL query string. The example in the README is the entire mental model: a request for image.jpg?width=100&height=200&mode=crop returns a resized, cropped image.

That simplicity is the point. A gallery page, a product listing or a content system with images of arbitrary size does not need a build step or a set of pre-generated derivatives. It points at the original and lets the server produce what the browser asked for. The README also mentions using picture and srcset without leaving your IDE, which is the modern way of asking for several widths of the same image.

The library describes itself as designed and hardened for server-side use, with low-latency disk caching to keep response times fast, and as easy to use with a CDN or behind a reverse proxy. It also says it works for both public and private images, with support for custom authorization rules, which is the case people forget about until a build server needs to resize an image that is not publicly reachable.

The URL API has a full command reference and a diagram of the fit modes, and the site is at imageresizing.net. The primary language of the repository is C#, and the default branch is develop rather than main.

Imageflow is the engine, and it is a native runtime

The plugin list makes the architecture clear, because one package does most of the work. ImageResizer.Plugins.Imageflow installs the Imageflow backend, and the README says Imageflow is what provides excellent image quality and file sizes, and is required for most image manipulation commands. If you are not using ASP.NET, you can use it directly through the Imageflow.Net package.

Imageflow itself is a native library, and it ships as two pre-release NuGet packages: Imageflow.NativeRuntime.win-x86 installs the 32-bit imageflow.dll, and Imageflow.NativeRuntime.win-x86_64 installs the 64-bit version, with a note to keep that package updated.

The 32-bit and 64-bit split is the practical detail to plan around. A project on a 64-bit server needs the win-x86_64 package, and both are marked as pre-release, so a plain install will not find them without the pre-release flag. Since the native DLL is what actually decodes and re-encodes your images, a mismatch there shows up as a runtime failure rather than a build error.

The v5 changes are described as major, with the goal of greatly improving image quality, file sizes, concurrency, maintainability and response times. The changelog lives in CHANGES.md, and the README suggests following the guidance in /resizer.debug when migrating from v4, which is the self-diagnostics page.

Five packages get you a working install

The basic installation guide in the README gives a five line Package Manager sequence, and the two native runtime packages come first because the Imageflow plugin needs them:

PM> Install-Package ImageResizer.WebConfig
PM> Install-Package ImageResizer.Plugins.Imageflow
PM> Install-Package Imageflow.NativeRuntime.win-x86 -pre
PM> Install-Package Imageflow.NativeRuntime.win-x86_64 -pre
PM> Install-Package ImageResizer.Plugins.HybridCache

There is one instruction that would have cost me time if I had missed it. Starting with ImageResizer v5, the README says to avoid nuget.packages and use the ProjectReference format instead in your projects. In practice that means the packages above, and then referencing the projects directly rather than pinning the packages from a feed.

The two structural packages are small in description but central in effect. ImageResizer includes the HttpModule for .NET Framework 4.7.2 and 4.8, and ImageResizer.WebConfig installs that HttpModule in Web.config. So the plugin is registered through configuration, and the module is what intercepts the image request in the first place.

HybridCache is the fifth package and it has the strongest language in the list. It is described as essential for scaling your website to high traffic, an optimised low latency disk cache with accurate space limiting, and the README says it replaces DiskCache and does everything better.

Almost all the ImageResizer plugins are on NuGet, and the README notes that in v5 the vast majority of plugin features were rolled into ImageResizer.Plugins.Imageflow, which is why so many plugins are deprecated as duplicating Imageflow functionality.

A self-diagnostics page replaces most troubleshooting

There is a troubleshooting section in the README that is worth reading before you have a problem, because it explains the tool you will use when you have one.

Most configuration and plugin installation issues can be resolved by checking the self-diagnostics page. The quick start says to install the ImageResizer.WebConfig NuGet package, run your app, and then visit /resizer.debug. If your local site is running at http://localhost:5000/, the diagnostics page is at http://localhost:5000/resizer.debug.ashx.

This is a good design for a library that has a native component, a plugin system, a URL syntax and a configuration file. Any of those can be misconfigured in ways that produce an unhelpful error, and a page that reports what the library actually sees at runtime turns guesswork into a reading.

Plugins can also be installed by hand rather than through configuration, which matters if you are not using Web.config. You add a reference to the plugin DLL in your project, then either insert an add name entry in the plugins section of Web.config or create an instance in Application_Start and install it:

  new PluginName().Install(ImageResizer.Configuration.Config.Current);

The managed API examples and the configuration reference are in the table of contents, and the repository has an examples directory with a BasicWebApplication, a ConsoleApplication, a StartHere project and an S3ReaderSample, plus an ImageResizer.Examples.sln.

The licence split is the part to read before installing

The licence section is short and it divides the packages into two groups, and the division is not the one you would guess from the list of features.

ImageResizer and ImageResizer.WebConfig are licensed under the Apache 2.0 license. ImageResizer.Plugins.Imageflow, .HybridCache, .AzureReader2 and .S3Reader2 require a commercial license or compliance with the AGPL 3.0.

So the core library and the module that installs it are permissive, and everything that does the actual image work, plus the cache and the cloud storage readers, is copyleft or commercial. That is a sensible arrangement for a project whose business is selling support and enterprise features, and an awkward one if you were expecting the whole thing to be free.

The AGPL route is worth understanding before you pick it, because the copyleft obligation travels with network use. If you run a site that lets users upload images and serve them resized, and you use the AGPL option, you are in the territory where the terms of the licence reach your service rather than your internal code.

The cloud readers are the two packages for images stored in Azure Blob storage and in Amazon S3, and the storage package for alternate image storage locations. On a project that keeps its images in object storage, those are not optional extras, so the licensing decision has to cover the whole set you need rather than the core alone.

The repository itself records a custom licence that GitHub cannot classify, with a LICENSE.md at the root, and there is a SECURITY.md alongside a CONTRIBUTING.md and a CHANGES.md.

A project that points you elsewhere for new work

The first line of the README body is a redirect, and it is the most consequential line in the document. If you can use .NET 5, 6 or 7, use Imageflow.Server in place of ImageResizer, and this readme is for ImageResizer 5.x for .NET Framework 4.x. Separate readmes exist for 4.x, 3.x and 2.x on their own support branches.

So the project has an explicit audience, and it is people maintaining .NET Framework applications. That is a large population, because .NET Framework applications tend to be long-lived internal or line-of-business systems, and they are exactly the kind of systems that serve a lot of user-uploaded images.

The maintenance picture is mixed, and the mixed part matters. The last push was on 2026-10-07, so the develop branch is being worked on. The most recent tags are v5.1.0-rc01 from 2025-06-26, and before that v5.0.13-preview09 and v5.0.12, both from September 2023, both tagged as patches for a libwebp vulnerability to malicious images.

That last detail is a good summary of how this project treats security. A native image decoder is a parser of untrusted input, and the project shipped tagged releases to close a libwebp issue affecting malicious images. The gap between those 2023 tags and the 2026 work on develop is worth noting if you are choosing a version, and the 4.x and 3.x support branches exist for people who cannot move.

Editorial conclusion

Adopt ImageResizer 5 if you maintain a .NET Framework 4.7.2 or 4.8 site and need on-demand resizing with a query string API, a disk cache and readers for S3 and Azure Blob storage. Do not adopt it for a new .NET Core or .NET 5, 6 or 7 project, because the README directs those users to Imageflow.Server instead. Before you install, check the licence of the packages you actually need, since ImageResizer and ImageResizer.WebConfig are Apache 2.0 while the Imageflow, HybridCache, AzureReader2 and S3Reader2 packages require a commercial licence or AGPL 3.0 compliance.

Frequently asked questions

Official sources

1. imazen/resizer on GitHub
2. Issues
3. Project website
4. README
5. Releases