Angry IP Scanner: a Java network scanner you build yourself

What Angry IP Scanner is for, and who ends up using it

Angry IP Scanner answers a narrow question: which addresses on this range respond, and what can I learn about each one. The README describes it as a network scanner with a GUI built on SWT, the Eclipse widget library, which is why the same application renders with native components on Linux, Windows and macOS rather than a single Java look. That choice matters to the audience. Someone who administers a mixed fleet of laptops and servers can hand out one build per platform instead of three unrelated utilities.

The intended user is closer to a network administrator or a developer debugging connectivity than to a security operations team. The README's contribution section is revealing: it says there are millions of different networks, configurations and devices, and asks people to submit a Pull Request when something does not work as expected, calling out macOS users specifically. That is the tone of a project whose correctness depends on the environment it runs in. Port behaviour, host discovery and vendor lookups vary by platform and by network, so the project relies on bug reports from people with a reproducible setup.

It is also a desktop tool, not a service. Nothing in the repository describes a daemon, an API server or an agent you deploy. You run it where you are sitting.

The Fetcher model: how a scan actually produces data

The architecture visible in the repository is a set of Fetcher classes under src/net/azib/ipscan/fetchers. The README points contributors at exactly that directory when describing how to debug: open the project in IntelliJ IDEA, run it in Debug mode, and put a breakpoint into the desired Fetcher class. So each piece of information about a host, whether that is a ping response, an open port or something else, is produced by a separate fetcher rather than by one monolithic scan routine.

That design has a practical consequence. Extending what the scanner reports does not mean editing a central scanning loop. It means adding a fetcher, which is why the README can treat contribution as a matter of reproducing a problem and fixing one class. It also means the cost of a scan is the sum of the fetchers you enable. If you turn on more checks, you send more packets and wait longer, and the accuracy of each column depends on the network between you and the target.

The GUI layer is SWT, which is a native-widget toolkit rather than Swing. The README states this is what provides native components for each supported platform. The trade-off is that the GUI is bound to platform-specific libraries, which is part of why builds are split by target: the Makefile exposes separate linux, linux64, win32, win64, mac and macArm64 targets, and the macArm64 target explicitly sets JAVA_HOME to a Java 21 installation before invoking Gradle.

Building Angry IP Scanner with Gradle and running your first scan

The README is explicit that Gradle is the build system and that the Makefile exists only as a convenience for people not familiar with Java: its own header comment says to use ./gradlew instead of make. The project requires Java 21; on Ubuntu the README lists the packages to install.

sudo apt install openjdk-21-jdk rpm fakeroot

After cloning, run the Gradle wrapper for your current platform. The README states this builds the app for the platform you are on and places the resulting binaries in build/libs.

./gradlew current

Then run the jar. The README gives this form directly.

java -jar <jar-file>

To see what targets exist, the README says to run ./gradlew or make in the project directory for the list of available targets. Building everything at once is possible with ./gradlew all, but the README warns that this is tested on Ubuntu only and that deb and rpm packages can be built only on Linux, while the Windows installer can be built on Windows only. The macArm64 target in the Makefile shows the pattern for Apple silicon, setting JAVA_HOME via /usr/libexec/java_home -v 21 and then listing the produced zip in build/libs.

The first real use is the same on every platform: launch the jar, enter an address range you are authorised to scan, and start the scan. Expect the run to take longer as you enable more fetchers, because each one adds traffic and waiting.

Where Angry IP Scanner is the wrong tool

The most concrete limitation is packaging. The README states plainly that deb and rpm packages can be built only on Linux, tested on Ubuntu, and that the Windows installer can be built on Windows only. If your team wants a reproducible pipeline that emits installers for all three platforms from one machine, the documentation does not promise that. The ./gradlew all target is described as tested on Ubuntu only, and the README points to the dependency list rather than claiming it works everywhere.

The second limitation is automation. Nothing in the README or the Makefile describes a command-line scanning mode, a machine-readable output format, or an exit code contract. The Makefile targets are build targets, not scan targets. If you need to scan a range from a cron job and parse the result, this repository does not document a path for that, and you would be relying on behaviour the README never states.

The third is that scanning is inherently environment-dependent, and the project says so. The README asks for pull requests when something does not work as expected, especially for macOS users, and notes that a problem is easy to fix if you have an environment to reproduce it. That is an honest admission that results can differ across platforms and networks. Treat any single scan as evidence, not proof.

How it differs from Advanced IP Scanner and from browser-based scanners

Advanced IP Scanner is the comparison people search for, and the difference is the platform story. Advanced IP Scanner is a Windows application. Angry IP Scanner is written mostly in Java with an SWT GUI and, according to the README, runs on Linux, Windows and macOS. If your fleet is mixed, that is the whole argument in one line. If everyone is on Windows and you want a signed installer without a build step, the Windows-only tool is the shorter path, and the README's note that the Windows installer can be built on Windows only does not change that.

Against the free web-based scanners that appear in the same searches, the difference is more fundamental. A browser-based scanner cannot see your private RFC 1918 ranges from outside your network, and it cannot use a Fetcher running on your machine. Angry IP Scanner is a local process with native GUI components, so it sees what your host sees. That is also its cost: it is software you install or build, not a page you open.

There is also a portability angle. The searches for a portable build are common, and the repository does not document an official portable distribution. What it does give you is source, a Gradle build and a jar you can run with java -jar on a host that has a Java 21 runtime.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-01. The most recent release listed is 3.10.0, dated 2026-08-31, following 3.9.3 in November 2025 and 3.9.2 in August 2025. So the project has a release cadence measured in months, and a CHANGELOG file sits at the top level of the repository for reading what changed between them. There is also a TODO.md at the top level, which is worth checking before you assume a gap is a bug rather than a known omission.

Upgrade cost is mostly a build-environment question. The README specifies openjdk-21-jdk, and the Makefile's macArm64 target pins JAVA_HOME to Java 21 through java_home -v 21. If your build host moves to a different JDK, that is the first thing to check. Because packaging is per-platform, an upgrade may mean rebuilding on each OS you support rather than once.

The licence is GPL-2.0, stated in both the README and the LICENSE file. The practical implication is that if you modify the source and distribute the result, the GPL's terms apply to that distribution. This is a description of the licence, not legal advice; if you plan to ship a modified build inside a product, have someone qualified read the licence.

Editorial conclusion

Adopt Angry IP Scanner if you need a cross-platform GUI scanner you can build from source and extend by writing a Fetcher class in src/net/azib/ipscan/fetchers, and if your use is limited to hosts you are authorised to scan. Skip it if you need a scriptable CLI in CI, a hosted online scanner, or a Windows-only installer you never have to compile: the README states the Windows installer can be built on Windows only, and the project ships no documented command-line interface. Before relying on it, verify three things: that openjdk-21-jdk is present on your build host, that ./gradlew current produces a jar in build/libs, and that the fetchers you intend to use behave on your own network, since the README asks users to submit pull requests when something does not work as expected, especially on macOS.

Frequently asked questions

Official sources

1. angryip/ipscan on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases