How to Check the Open Ports on Your Computer or Network
Understanding which ports are open on your system is one of the most practical skills in networking — whether you're troubleshooting a connection issue, hardening your security, or verifying that a server is listening correctly. The process varies depending on your operating system, your goals, and how deep you need to go.
What Is an Open Port, Exactly?
A port is a numbered communication endpoint — a logical channel through which your device sends and receives data. Your computer has 65,535 possible ports, each identified by a number. When a service or application is actively listening for incoming connections on a port, that port is considered open.
Common examples:
- Port 80 — unencrypted HTTP web traffic
- Port 443 — HTTPS (encrypted web traffic)
- Port 22 — SSH remote access
- Port 3389 — Windows Remote Desktop Protocol (RDP)
- Port 25 — SMTP email
An open port isn't inherently dangerous — it just means something is listening. The concern is when unintended services are exposed, or when ports are open to the public internet without proper security controls.
Why You'd Need to Check Open Ports
The reasons vary widely:
- Security auditing — identifying services exposed to the internet that shouldn't be
- Troubleshooting — confirming an application is actually listening on the expected port
- Firewall verification — making sure rules are working as intended
- Server configuration — checking that a web server, database, or game server is accessible
- Development work — verifying that local services are binding correctly during testing
Each use case points you toward a slightly different tool or method.
Checking Open Ports on Windows ��️
Using the Command Prompt (netstat)
The built-in netstat command is the fastest starting point on Windows:
This displays all active connections and listening ports, along with the PID (Process ID) so you can trace which application owns each port. To filter for only listening ports:
To identify which program corresponds to a PID, open Task Manager, go to the Details tab, and match the PID column.
Using PowerShell
PowerShell offers a more structured view:
This returns a table of listening TCP ports with local address, port number, and owning process ID.
Using Third-Party GUI Tools
Tools like TCPView (from Microsoft's Sysinternals suite) present open ports and associated processes in a live, visual interface — useful if you're uncomfortable parsing command-line output.
Checking Open Ports on macOS and Linux 🐧
netstat (macOS/Linux)
The flags break down as: t = TCP, u = UDP, l = listening only, n = numeric (show port numbers instead of service names). This is widely supported across distributions.
ss (Linux — modern replacement for netstat)
On most modern Linux distributions, ss is preferred:
Faster and more feature-rich than netstat, ss provides the same core output with additional filtering capabilities.
lsof (List Open Files)
lsof treats network connections as open files (which they technically are in Unix-based systems). This command shows listening ports alongside the owning process name — handy for pinpointing exactly which application holds a port.
Scanning Ports From the Outside: Remote Checks
The methods above show you what's open from the machine's own perspective. But a firewall might block external access to a port even if the service is technically listening locally. To see what's actually reachable from the internet or another device on your network, you need to scan from the outside.
Nmap
Nmap (Network Mapper) is the industry-standard tool for this:
Replace the IP with your target. The -sV flag attempts to detect the service version running on each open port. Nmap can scan a single host, a range, or an entire subnet — and runs on Windows, macOS, and Linux.
Web-Based Port Checkers
For a quick external check of your own public IP, browser-based tools let you test whether a specific port is reachable from the internet without installing anything. You enter your IP and port number, and the tool attempts a connection from its server.
Key Variables That Affect What You'll See
| Variable | How It Affects Results |
|---|---|
| Operating system | Different commands, output formats, and default services |
| Firewall rules | Can hide locally open ports from external scans |
| Scanning from local vs. remote | Local tools show the OS view; remote scans show the network view |
| TCP vs. UDP | UDP ports require different scan flags and are harder to detect reliably |
| User permissions | Some commands require admin/root to show full process ownership |
| Virtualization or containers | VMs and Docker add network layers that affect port visibility |
Interpreting the Results
When you see a port listed as LISTEN or open, the next question is always: should this be open? Cross-referencing the port number against the service you expect — and checking which process owns it — tells you whether the result is intentional or a flag for further investigation.
UDP ports add another layer of complexity. Unlike TCP, UDP doesn't use a handshake, which makes open UDP ports harder to confirm through scanning alone. Tools like Nmap have specific UDP scan modes (-sU) but they're slower and less definitive.
The right method, and the right interpretation, depends heavily on whether you're looking at a home machine, a managed server, a containerized environment, or a cloud-hosted instance — each of which presents its own network topology and firewall layer between the service and the scan result.