# NeeView: a Windows image viewer that reads inside compressed archives as if they were folders

> NeeView is a WPF desktop image viewer whose distinguishing feature is that it browses images inside zip, rar, 7z and comic archives as though they were directories, with PDF and video support, mouse gestures and a plugin host. It is a single-machine desktop application for Windows, not a library.

**neelabo/NeeView** — An image viewer that allows you to browse images in folders and compressed files like a book. Powerful customization is available.

- Repository: https://github.com/neelabo/NeeView
- Website: https://neelabo.github.io/NeeView/
- Stars: 1,064 · Forks: 54
- Language: C#
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/neelabo-neeview

## Archives as folders, which is the whole idea

NeeView is described as an image viewer that allows you to browse images in folders and compressed files like a book, with powerful customization available.

The compressed file support is the feature that distinguishes it from a general image viewer. The README lists zip, rar, 7z, lzh, cbr, cbz, cb7 among the supported formats, and adds recursive compressed file support, meaning an archive inside an archive. The cbr, cbz and cb7 names are the comic book archive conventions, and their presence alongside the generic ones says plainly that the primary audience includes people with large comic collections who do not want to unpack anything.

The effect on the user is that the file system stops being the unit of organisation. You point the viewer at a directory, and it presents a tree in which an archive appears as a folder whose contents you can enter, and images inside it can be viewed, paged through, and rotated without ever being written to disk. For a collection of thousands of images that live in hundreds of archives, that is the difference between browsing and extracting.

The format list also includes WIC images, which is the Windows Imaging Component, so any format the operating system's own codec supports is readable in addition to the explicit list of bmp, jpg, gif, tiff, png, webp and ico. The README lists PDF support and video play support as separate features, which means the viewer is a general document and media browser with images as its centre rather than a pure image tool.

The remaining features in the list describe the viewing experience itself: touch operation, mouse gesture support, key customization, movement, rotation and scaling by dragging, loupe mode, facing mode for spread views, full screen mode, and a slide show. Facing mode and the slide show are the two that matter for the archive browsing use case, since a comic reader is essentially a paged reader with zoom.

The primary language of the repository is C#, the licence is MIT, and the project is a Windows desktop application using WPF, with the topics naming csharp, dotnet, image-viewer, picture-viewer, windows-desktop and wpf.

## Two extension mechanisms: Susie plugins and command scripts

There are two distinct ways to extend NeeView, and they sit at different levels.

The first is the Susie plugin support, and the repository has a whole set of directories for it. There is a NeeView.Susie/ directory for the plugin host and a NeeView.Susie.Server/ directory alongside it, and the NeeLaboratory.Runtime/ and NeeView.Interop/ directories suggest the interop layer between the plugin and the application. Susie is a plugin format for image and comic viewers, and supporting it means NeeView can load plugins written for a different ecosystem, which is a compatibility decision rather than a feature list item.

The second is command extension by scripts, with a SampleScripts/ directory in the repository. Where a Susie plugin extends what the viewer can do with an image, a command script extends what the viewer can do in response to an action. The README lists command extension by scripts alongside the plugin support as two separate capabilities, and the existence of a samples directory means there is a reference to read rather than only a specification.

Two more integration points are worth naming. Image drop from web browser means you can drag an image out of a browser window and into the viewer, which is a small thing that removes a genuinely annoying step when you are collecting reference material. And the remote directory, NeeLaboratory.Remote/, along with NeeLaboratory.IO.Search/ for file search, suggests the application can browse sources that are not the local disk, or at least search across them.

The rest of the top-level tree is worth reading for a different reason: it shows that the application is split into an unusual number of separate projects, and that some of them are forks or submodules of third-party code. NeeView/ is the application itself, with NeeView.UnitTest/ for tests, NeeLaboratory.SourceGenerator/ for source generation, AnimatedImage/ for animated image support, SevenZipSharp/ and Vlc.DotNet/ as vendored dependencies, and a .gitmodules file indicating submodules. MakePackage/ and the two PowerShell scripts, CreateEmbeddedDocs.ps1 and CreateVersionProps.ps1, are the build and packaging machinery, and NeeViewVersion.xml holds the version data.

The presence of a separate SourceGenerator project is notable for a WPF application. It means some of the repetitive code, and notably the view models, are generated rather than written, which is a substantial maintainability decision for an application of this size.

## The per-user installer change, which breaks upgrades from v44.1

The Notice section of the README is the most operationally important part of it, and it is easy to skim past because it is short.

Starting with v45.0, the installation type changes to Per-User, eliminating the need for administrator privileges. Per-Machine installations from v44.1 or earlier cannot coexist and must be uninstalled first. If the new installer detects a v44.1 or earlier installation, it will display a dialog prompting uninstallation and halt the installation process. User data will be carried over.

That is a breaking change in the installer rather than in the application, and the mechanism it uses is worth noticing. The new installer detects the old installation, stops itself, and asks the user to uninstall. That avoids the failure mode where the two installation types overwrite each other's registry state and leave a broken installation. The user data is carried over, so settings and any per-user state survive.

For an administrator rolling this out across a set of machines, the practical consequence is that this is not an in-place upgrade for anyone on v44.1 or earlier. The order of operations has to be uninstall first, then install, and the registry and file placement differ between the two installation types, so a scripted rollout has to handle the transition rather than assume the installer does it.

It is also a sign of direction. A per-user install for a desktop viewer is the modern expectation, and the fact that the project has made this change at the 45.0 boundary suggests the maintainer is keeping the application current with how desktop software is distributed on Windows, rather than keeping it in the shape it had when the per-machine model was the default.

The download channels reflect a similar awareness. The README lists GitHub Releases, the Microsoft Store, and Vector as the places to get it,

## Versioning and branch strategy, read from the README

The README documents a versioning and branching scheme, and both are unusual enough to be worth understanding before you decide how to track the project.

The version format is MAJOR.MINOR.BUILD. The MAJOR version is updated with any feature additions or changes. If there are no changes in functionality, such as bug fixes, the MINOR version is updated. The BUILD version is automatically assigned the number of commits up to that revision, and it is internal and not public.

So the public version has two components, and the first is bumped aggressively. A MAJOR bump for any feature addition means the visible version number changes shape more often than a semantic versioning scheme would, and the BUILD component being internal means the public number does not tell you which commit you are running. The release list illustrates it: 46.3 on 2026-08-09, 46.2 on 2026-08-02 and 46.1 on 2026-07-27, three releases in a fortnight with single-step minor increments for what are presumably small changes.

The branching strategy has three named kinds. master is the main development branch, and basically pull requests are accepted here. version-XX branches are for each major version, and when development of the next major version begins on master, a branch is created to maintain the current major version. feature-XX branches are for feature development, removed when merged into master, and are explicitly described as working branches that are not guaranteed in any way.

That last sentence is a useful piece of honesty. A feature branch that is not guaranteed in any way is one you should not deploy from, and the combination with the version-XX maintenance branches gives you a way to stay on a known major version while master moves on.

The repository is not archived and the last push was on 2026-08-09, the same day as the 46.3 release, so the project is being worked on. The default branch is master, which is the development branch rather than a release branch, so a clone of the default branch gives you the current development state rather than the last stable release. The GitHub Releases page, which the README lists as a download source, is where the packaged builds are.

The LICENSE.md file is present at the top level and the licence is MIT, and there are also two third-party licence files, THIRDPARTY_LICENSES.md and a variant with _CODEIN.md in the name, which is where the terms for the vendored SevenZipSharp and Vlc.DotNet dependencies are recorded.

## Where NeeView is the wrong tool

There are three limits, and the first one is a hard platform constraint.

NeeView is a Windows-only application. The system requirements are Windows 10 64bit or higher, the topics are windows-desktop and wpf, and the development environment is Visual Studio 2026 with .NET Desktop Development and desktop development in C++. If your images live on a Linux workstation, a Mac or a NAS appliance, there is no version of NeeView for you, and this is not a Wine-and-hope situation that the documentation addresses.

The second is that the compressed file support is a browser feature, not an extraction tool. The archives are read in place, which is what makes the browsing pleasant, but it also means the viewer's ability to handle a large archive is bounded by the library it uses to read it. The tree shows SevenZipSharp/ as a vendored dependency and Vlc.DotNet/ for video playback, and both are third-party components whose behaviour and update cadence you do not control. A corrupt or unusual archive, or a format the vendored library handles differently from the standalone tool, will surface as a failure inside the viewer rather than as a message from the archive tool.

The third is the plugin story, and it is narrower than the two extension mechanisms suggest. The Susie support is for the Susie plugin ecosystem specifically, and the script extension is command extension by scripts. Neither is a general scripting API into the application, and neither is documented in the README beyond a bullet point and a SampleScripts/ directory. If your requirement is to script the viewer in depth, to drive it from another application, or to extract images in bulk with renaming, the documentation visible here does not promise that, and the scripting that exists is aimed at adding commands rather than at automation.

And there is a fourth, more mundane point. An image viewer that reads archives and plays video is a fairly heavy desktop application to install on a locked-down machine, which brings the per-user installer change into focus. The change to per-user installation removes the administrator requirement, which is the right call for a viewer, but it also means the application is now installed per user rather than once per machine, which changes how it behaves on a shared or managed workstation where a kiosk account and a user account would each need their own copy.

## NeeView against the alternatives

There are two other ways to browse images, and the difference in approach is instructive.

The first is the archive manager plus a normal image viewer. You open a zip or a rar in an archive tool, extract the images to a temporary folder, and open them in whatever viewer you have. This is what most people do, and it works. The cost is the extraction step, the temporary files, and the loss of the archive's own structure once it is flattened. For a comic with fifty pages, extracting and re-extracting is the difference between turning a page and finding the folder.

The second is a dedicated comic reader, which is what NeeView's cbr, cbz and cb7 support is aimed at. A dedicated reader usually has a page-oriented interface, a library database, and no interest in general image formats. NeeView's approach is different: it is a general image and document browser that has learned to enter archives, and it keeps the file system as the organising principle rather than replacing it with a library database. For someone whose images are already organised in directories and archives on disk, that is the better model. For someone with a large comic collection that they would want in a database with metadata, cover art and reading progress, the dedicated reader is the better tool.

The third option is the platform's own viewer. Windows has a built-in image viewer, which covers casual use. The difference is that the built-in tooling does not give you the gestures, the loupe, the facing mode, the slide show, the plugin host or the archive formats the README lists, and it is not the application you configure the way NeeView can be configured.

So the deciding question is how the images are organised and who does the organising. If they are on disk in directories and archives, and you want to browse them the way you browse files, NeeView's model is the right one. If you want a library with metadata and reading progress, a dedicated reader fits better. And if you only need to look at the occasional image, the operating system already does that.

## Conclusion

Adopt NeeView if you keep your images inside archives, including comic book archives, and you want a single Windows application that treats those archives as directories rather than something you unpack first. Do not adopt it if you need cross-platform support, because the system requirements name Windows 10 64-bit or higher, and do not expect a plugin API for anything other than the documented Susie plugins. Verify first that the installer type you are about to use matches your existing installation, because per-user and per-machine installs cannot coexist from v45.0, and that the archive formats you rely on are among those the viewer supports.

## FAQ

### What image and archive formats does NeeView support?

The README lists bmp, jpg, gif, tiff, png, webp, ico and WIC images for images, and zip, rar, 7z, lzh, cbr, cbz and cb7 for compressed files, with recursive support for archives inside archives. PDF and video playback are also supported.

### What changed with the NeeView v45.0 installer?

Starting with v45.0 the installation type changed to Per-User, so administrator privileges are no longer needed. Per-Machine installations from v44.1 or earlier cannot coexist and must be uninstalled first; the new installer detects them, prompts for uninstallation and halts, and user data is carried over.

### How can NeeView be extended?

Two ways are listed: Susie plugin support, and command extension by scripts, with a SampleScripts directory in the repository holding examples. The top-level tree also shows a NeeView.Susie directory and a NeeView.Susie.Server directory for the plugin host.

### What are NeeView's system requirements?

Windows 10 64bit or higher. The project is a WPF application, and the development environment section specifies VisualStudio 2026 with the .NET Desktop Development workload and desktop development in C++.

## Sources

- [License: MIT](https://github.com/neelabo/NeeView/blob/master/LICENSE)
- [neelabo/NeeView on GitHub](https://github.com/neelabo/NeeView)
- [Project website](https://neelabo.github.io/NeeView/)
- [README](https://github.com/neelabo/NeeView/blob/master/README.md)
- [Releases](https://github.com/neelabo/NeeView/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/neelabo-neeview