NAPS2: a cross-platform scanning front end with a .NET SDK underneath

What NAPS2 solves, and who ends up using it

Scanner software is the part of the document pipeline that vendors treat as an afterthought. A device ships with a driver and a bundled utility that is often Windows-only, occasionally abandoned, and rarely able to talk to more than one driver standard. NAPS2 exists to sit above that layer. The README describes it as a document scanning application with a focus on simplicity, and the supported driver list is the substance of the claim: WIA, TWAIN, SANE and ESCL. Those four cover most of the ground between a consumer flatbed on Windows and a network multifunction device that speaks eSCL over HTTP.

The audience splits in two. The first group is people who own a scanner and want pages as a PDF without fighting the vendor utility. They install the desktop app, pick a device, scan, and save. The second group is developers. NAPS2.Sdk is published on NuGet as a scanning library supporting the same four standards on the same three platforms, and the repository keeps it in its own top-level directory with its own samples project. That second audience is the reason the codebase is structured the way it is: the GUI applications are consumers of the library, not the other way round.

The repository layout makes the split explicit. NAPS2.Lib, NAPS2.Images, NAPS2.Escl and NAPS2.Internals are the shared layers. NAPS2.App.WinForms, NAPS2.App.Wpf, NAPS2.App.Gtk and NAPS2.App.Mac are separate front ends over them. There is also NAPS2.App.Console, which is worth knowing about if you want scanning without a window.

The driver abstraction and where ESCL fits

The mechanism is a driver abstraction with per-platform implementations. On Windows the application reaches scanners through WIA and TWAIN. On Linux it goes through SANE, which is why the README lists libsane among the system requirements alongside GTK 3.20+ and glibc 2.27+. On macOS it uses the platform's scanning support. ESCL is the odd one out and the most interesting: it is a network protocol rather than a local driver interface, so an eSCL-capable device can be reached without the vendor's driver stack at all.

The repository treats ESCL as its own subsystem rather than a thin adapter. NAPS2.Escl holds the protocol work, NAPS2.Escl.Server implements the server side, and NAPS2.Escl.Usb exists as a separate entry. That is a meaningful amount of code for one protocol, and it suggests the maintainer expects eSCL to carry real weight rather than serve as a fallback. For anyone deploying scanners on a network, that is the path worth testing first, because it removes the driver installation step entirely.

The image layer is similarly abstracted. NAPS2.Images has backends for GDI, GTK, ImageSharp, Mac and WPF. That is five implementations of the same imaging surface, which is what you get when a single codebase has to render and process bitmaps on three operating systems with different native toolkits. The cost is real: more code to maintain, more places for platform-specific bugs. The benefit is that the scanning and OCR logic above it stays platform-neutral.

OCR is delegated. The README states that optical character recognition is available using Tesseract, which is an external project rather than something NAPS2 implements itself. That matters for deployment: OCR quality is Tesseract's, and OCR availability depends on Tesseract being present and on the language data you have installed.

Installing NAPS2 and running a first scan

The README does not contain install commands. It points to the downloads page at naps2.com/download, and that is where the packaged builds for Windows, macOS and Linux come from. There is no documented package-manager command in the repository README, so the honest instruction is: get the build for your platform from the downloads page, then run it.

System requirements are stated plainly, and they are worth checking before you download. Windows 7 or later on x64 or x86, macOS 10.15 or later on x64 or arm64, and Linux on x64 or arm64 with GTK 3.20+, glibc 2.27+ and libsane present. On Linux, libsane is not optional: it is the path to the scanner.

If you are building from source rather than downloading, the README defers to the GitHub wiki page titled Building & Development Environment. The repository is a .NET solution, NAPS2.slnx, with a NuGet.Config at the root, so the expected toolchain is the .NET SDK. The README does not spell out a build command.

For developers, the SDK is the entry point. The README links the NuGet package NAPS2.Sdk and points at the NAPS2.Sdk directory and its samples.

A first scan through the desktop app

The desktop flow is the one the README describes: scan from a supported scanner, organize pages as you like, and save as PDF, TIFF, JPEG or PNG.

First, confirm the scanner is visible to the operating system before opening NAPS2. On Linux that means SANE can see it; on Windows it means WIA or TWAIN has a driver. NAPS2 sits above those layers, so a device the OS cannot see will not appear in NAPS2 either.

Second, open the application and select the device from the scanner list. The README's supported list is WIA, TWAIN, SANE and ESCL, so a device that only exposes a proprietary interface will not show up.

Third, scan. Pages land in the application's page list, where you can organize them before saving. That intermediate step is the main practical difference from a one-shot scanner utility: you get to fix the page order before committing to a file.

Fourth, save. Choose PDF, TIFF, JPEG or PNG. If you want searchable output, enable OCR, which runs through Tesseract. The README does not document which Tesseract build ships with which platform package, so if OCR matters to you, verify it on your own install rather than assuming it is bundled everywhere.

For a .NET project, the equivalent starting point is adding the SDK package and following the samples directory. The README's own pointer is the NAPS2.Sdk folder, and the samples project is NAPS2.Sdk.Samples.

Where NAPS2 is the wrong tool

The clearest failure mode is a scanner without a standard driver. NAPS2's four supported interfaces are WIA, TWAIN, SANE and ESCL. A device that only ships a proprietary vendor SDK, with no TWAIN or WIA layer and no eSCL endpoint, is outside that set. No amount of configuration in NAPS2 will make it appear. This is not a defect in NAPS2; it is the boundary of the abstraction, and it is the first thing to check when someone reports that their scanner is not detected.

The second limitation is platform. Windows 7 and later, macOS 10.15 and later, Linux with GTK 3.20+ and glibc 2.27+. Older Linux distributions, or ones built against an older glibc, are not supported. The README does not describe a workaround, and there is no documented static build that sidesteps the glibc requirement.

The third is licensing, and it is the one most likely to bite a commercial team. The top-level licence is GNU GPL 2.0 or later. Several components are LGPL 2.1 or later instead: NAPS2.Escl.*, NAPS2.Images.*, NAPS2.Internals and NAPS2.Sdk. NAPS2.Sdk.Samples is MIT. So the answer to "can I use NAPS2.Sdk in my product" is not the same as the answer to "can I use NAPS2". The SDK is LGPL, the application is GPL. The README states the split; it does not explain the consequences, and that is a question for your own legal review, not for this article.

A fourth, softer limitation: OCR is Tesseract. If your documents need layout analysis, table extraction or handwriting, Tesseract's output is what you get, and the README makes no claim beyond basic OCR availability.

How NAPS2 compares with a scripted SANE or vendor utility approach

The obvious alternative on Linux is driving SANE directly, through scanimage or a small script. The difference in approach is where the abstraction lives. SANE alone gives you a device interface and a command. You get the raw image and you handle page assembly, format conversion, rotation and OCR yourself, usually by piping into other tools. NAPS2 puts a page model, an image layer and a save pipeline above the driver, and gives you a window to reorder pages in. If your workflow is one command producing one file, SANE alone is less machinery. If your workflow involves multi-page documents, mixed formats and a human deciding what to keep, NAPS2's page list is the part you would otherwise build.

On Windows, the alternative is the vendor utility that came with the device. Those utilities are typically tied to one vendor's hardware and one Windows version, and they rarely produce anything but PDF or JPEG. NAPS2's advantage is breadth: one application, four driver standards, three platforms, four output formats. Its disadvantage is the same breadth: it cannot use vendor-specific features that the standard driver interface does not expose, like a particular device's advanced colour calibration or its proprietary duplex modes.

For developers, the alternative to NAPS2.Sdk is writing the driver bindings yourself. TWAIN has a C API with a data source manager, WIA is a COM interface on Windows, SANE is a C library, and eSCL is HTTP with XML. Handling all four across three platforms is a substantial amount of interop code, which is exactly the work NAPS2.Sdk already contains. The trade is that you take an LGPL dependency instead of owning the code.

Maintenance, releases and what the licence split means in practice

The repository is not archived, and the last push was on 2026-10-30. The most recent releases listed are v8.6.0 on 2026-10-25, v8.5.1 on 2026-10-12 and v8.5.0 on 2026-10-12. The CHANGELOG.md at the repository root is where the details live. The README does not document an upgrade procedure, and it does not describe a migration path between major versions.

Upgrade cost for the desktop application is low: it is an installed application, and the releases are versioned. Upgrade cost for the SDK is a normal NuGet version bump, with the usual caveat that a major version can change the API. The README does not promise API stability, so pin the SDK version and read the changelog before moving.

The licence split is the practical detail. NAPS2 as a whole is GNU GPL 2.0 or later. NAPS2.Sdk, NAPS2.Escl.*, NAPS2.Images.* and NAPS2.Internals are GNU LGPL 2.1 or later. NAPS2.Sdk.Samples is MIT. If you are building a proprietary application and want to embed scanning, the SDK's LGPL terms are the relevant ones, not the application's GPL. If you are modifying the desktop application and distributing it, the GPL applies. The README lists these; it does not interpret them, and the interpretation depends on how you link and distribute, which is a question for a lawyer rather than a README.

Editorial conclusion

Adopt NAPS2 if you need one scanning front end across Windows, macOS and Linux, or if you are writing .NET code and want the NAPS2.Sdk to handle WIA, TWAIN, SANE and ESCL behind one API. Do not adopt it if your scanner only ships a proprietary vendor driver with no TWAIN or WIA interface, or if you need a fully permissive licence across the whole application rather than the LGPL subsets. Before committing, verify three things on your own hardware: that your scanner appears in NAPS2's device list at all, that the ESCL path works if that is how you intend to connect, and which licence actually applies to the components you plan to ship. The licence split is the detail most likely to surprise a team that reads only the top-level LICENSE file.

Frequently asked questions

Official sources

1. cyanfish/naps2 on GitHub
2. Issues
3. Project website
4. README
5. Releases