You don't need to install anything to find out which of your ports are open. A web-based port scanner probes a target from a remote server and shows you what answered — the same TCP connect probes Nmap performs, run from someone else's machine. Used against targets you own, it's the quickest possible answer to the question "what does my attack surface actually look like from the internet?"
You can do exactly that right here: our free online port scanner checks 13 common service ports on any target you own and explains every result. This guide covers how to use it well — and how to read what it tells you.
Why scan from a remote server at all?
Running a port scanner from your own machine answers a different question than the one you care about. From inside your network, you see your internal reality: the ports open through local firewalls, on internal interfaces, behind NAT. From the outside, you see what an attacker sees — and those are frequently different things.
A security group rule that allows 3306 from "everywhere." A staging server still listening on 8080. A management interface on 8443 that someone exposed for a client demo in 2024. None of these show up from the inside, because inside, they're just... working. External perspective is the point. This is the same reason external attack-surface monitoring exists as a category.
Reading the results
An online scan classifies each port it checks into three states:
- Open — a service answered. This is exposure. Everything else on this page is about deciding whether each open port should be.
- Closed — the host replied that nothing is listening. The host is reachable; that specific door doesn't exist. Generally good news, and useful for confirming the scan worked.
- Filtered — silence. A firewall dropped the probe without answering. Usually what a properly configured firewall looks like, though it can also mean a network path problem.
The critical habit: treat every open result as a question, not a finding. "Something answered on this port — what is it, and did I intend to expose it?" Open port 443 serving your web app: intended. Open port 22 with password authentication enabled to the whole internet: probably not what you meant.
Ports that matter most
Most online scanners check a focused set of common ports. These are the ones worth knowing on sight:
| Port | Service | Why it matters | |---|---|---| | 22 | SSH | Remote shell — brute-force target, should be key-auth and ideally IP-restricted | | 80 | HTTP | Web traffic, usually redirects to 443 — fine open, but check what serves it | | 443 | HTTPS | Your public web presence — should be open, and should be the only web entry | | 3389 | RDP | Windows remote desktop — historically abused, never should face the internet | | 8080 / 8443 | Alt HTTP | Staging apps, admin panels, dev servers — the classic forgotten exposure | | 3306 / 5432 / 27017 | Databases | Should essentially never be internet-facing |
If a scan shows any database port, RDP, or an unfamiliar 8080, stop and verify what's listening before anything else. Those are the exposures that end up in breach reports.
Limitations of a quick web scan
A fast online check is a surface map, not an assessment. Know what it can't do:
- Limited port sets. Most web scanners check tens of ports, not all 65,535. A service on 8126 stays invisible. Full-range scanning is heavier and slower — that's a job for a dedicated scan.
- No version detection. "Open" doesn't tell you the software or version behind the port, which is where actual vulnerability findings come from.
- No application testing. An open 443 says nothing about the web app behind it. DAST — like OWASP ZAP — is the layer that tests the application itself.
- UDP is usually skipped. Most web-based tools are TCP-only, and UDP services (DNS, SNMP, various game and management protocols) stay invisible.
So the honest workflow is: quick online scan for awareness, then a real pipeline — full-range Nmap with service detection, followed by CVE checks (Nuclei) and web app testing (ZAP) on what the map found. Our what-is-a-port-scanner guide explains the underlying mechanics if you want the details.
Doing it safely and legally
Scan only targets you own or are authorized to test — ideally by an IP or hostname you control, with sign-off if it belongs to a client or employer. Don't scan shared hosting neighbors, cloud provider infrastructure you don't own, or anything where "I was curious" is your authorization. Reputable online scanners enforce their own rules about this too; if a tool lets you scan anything with no checks, that's a signal about the tool.
The step after the port scan
VulnScanners started as exactly this kind of check and grew into the pipeline that should follow it. A hosted scan maps your ports with Nmap from clean, isolated infrastructure, fingerprints every service it finds, runs Nuclei's CVE and exposure templates against the results, and can follow with a ZAP active scan on web targets — all delivered as parsed, severity-rated findings in a client-ready PDF report.
Run a free scan on a target you own: the port map is the first page, and what's behind the ports is the rest.