An open port proves only that something is accepting or sending packets on that number, and it does not prove which application is running. A common network ports list is a curated translation table from a numeric port to the registered service name, the usual transport protocol, and a short description. It is a registration hint, not a live detection result, and IANA itself warns that an assigned number does not endorse an application and does not prove observed traffic is good. Servers can listen on unusual ports, several registered names can map to one number, and a packet using a registered port can easily belong to a different program running on the same host, behind a load balancer, or on a non-standard port. Use the list to translate a number into a likely service before checking the actual endpoint with platform-native tools, service configuration, logs, and network policy.
Why an open port never proves which application is running
Port assignments describe the convention for a number, not the identity of the software bound to it on a specific host. Three everyday reasons break the assumption that port equals application, and each one matters when you read a ports list.
First, administrators can rebind any service to any port. An operator can run HTTPS on 8443, SSH on 2222, or PostgreSQL on 5433 without violating any network rule. From the outside, the packet still arrives at port 8443, but the application is no longer the one the registry associates with that number. The numbers you see in production traffic are configuration choices, not facts about the world.
Second, the same number can carry multiple registered services, especially in the User Port range from 1024 through 49151. A single TCP port can be listed for both a vendor product and an open-source alternative, and a port absent from a curated list may still be valid or widely deployed. Registration assigns a name to a number; it does not grant that name exclusive ownership.
Third, firewalls, proxies, and tunnels rewrite or translate ports. Reverse proxies terminate TLS on 443 and forward to an internal port such as 3000 or 8080. Containers and service meshes frequently listen on high ports that a curated list intentionally does not enumerate. The port you observe at the edge is rarely the port the application is bound to internally, so translating only the outer number leaves the real listener invisible.
What a common network ports list actually provides
A common network ports list gives you a fast lookup from a number to a likely service. It tells you that 443 is associated with HTTPS, that 5432 is associated with PostgreSQL, and that 25, 110, 143, 465, 587, 993, and 995 cover the standard mail protocols and their TLS variants. Each row has one numeric port, the selected IANA service name, one or more transport protocols, a short description, and a category used by the filter.
Two properties matter for interpretation. Coverage is curated, not exhaustive: the table covers familiar web, mail, file transfer, remote access, directory, database, messaging, printing, container, and core network services, not every IANA assignment. Search matches four fields: the port number, service name, description, and category, so a query for 443 returns HTTPS, a query for PostgreSQL returns 5432, and a query for mail returns the SMTP, POP3, IMAP, message submission, and their TLS variants together.
The list is a starting point, not a verdict. Use it to narrow a number into a candidate service, then verify the application against the actual host before drawing any conclusion.
Looking up a port with the Common Network Ports List tool
The tool lives at Common Network Ports List. Use it to translate a number into a likely service before checking the endpoint directly, and treat every row as a hint rather than a detection result.
- Enter a port number, service, product, or description in the search field. A query for 443 returns the HTTPS row, a query for PostgreSQL returns 5432, and a query for mail returns the SMTP, POP3, IMAP, message submission, and their TLS variants together.
- Optionally filter the visible rows by TCP or UDP and by service category. The protocol filter distinguishes TCP from UDP where that distinction is useful, and the category filter can isolate databases, web services, network infrastructure, remote access, or another supported group without changing the underlying reference data.
- Review the matching registration hints and read each row as a translation from number to likely service, never as a claim about your host or its security state.
- Copy the visible rows as tab-separated text when you need a tab-separated reference for tickets, notes, runbooks, or study material. Only the currently visible rows are exported.
- Treat missing rows as outside the curated set. A port absent from the table may still be valid, registered, private, ephemeral, or widely used by convention; absence means only that it is outside the curated rows, not that the number is invalid or unused.
The tool runs entirely in your browser, does not send your query or copied result to any server, and updates results immediately. No part of your lookup leaves the page, so it is safe to use against internal IP ranges or partial inventories.
Confirming the application behind an open port
Once the list gives you a candidate service, confirm it with evidence from the actual host. On Linux, ss -tulnp and netstat -tulnp show the listening process and PID, and lsof -iTCP:443 -sTCP:LISTEN narrows the search to a single port. On Windows, netstat -ano -p TCP lists the listening PID, and Get-Process -Id <pid> or Task Manager maps the PID to the executable. On macOS, lsof -nP -iTCP -sTCP:LISTEN gives a similar result without the elevated shell.
Process evidence is not the final word either. A reverse proxy may listen on 443 and forward to an unrelated application on 3000. In that case, follow the connection: read the proxy configuration, inspect the upstream block, and trace the request with packet capture or service logs. Look at TLS certificates with openssl s_client -connect host:443 or browser developer tools to confirm the actual service. Only the combination of process, configuration, traffic, and endpoint identifies the application.
For firewall policy, the same principle applies. A list of common ports is not an allowlist. Verify direction, source, destination, protocol, authentication, encryption, business owner, and least-privilege scope before opening any port. See the firewall allowlist guide for a fuller treatment of that mistake, because the same fallacy that an open port proves the application also tempts teams to treat a registered number as safe to expose.
Port number ranges that change what a lookup means
The interpretation of a port number depends on its range, and IANA divides the number space into three bands described in RFC 6335.
| Range | Name | Operational meaning for a lookup |
|---|---|---|
| 0 – 1023 | System Ports | Reserved for well-known services that usually need administrator privileges to bind; widely recognized and stable. |
| 1024 – 49151 | User Ports | Assigned by IANA to specific services and products on request; many are vendor-specific and may overlap with custom deployments. |
| 49152 – 65535 | Dynamic / Private Ports | Used for ephemeral client ports and not assigned to a single service; high-numbered traffic is usually a client, not a server. |
The Common Network Ports List includes common System and User Ports but does not enumerate the dynamic range. A high-numbered port you see in the wild is almost always an ephemeral client port from a short-lived connection, not a service to look up. Conversely, a User Port assignment is only a convention, so seeing 5432 does not guarantee PostgreSQL is running; the operator could have moved the database to 5433 or bound a different program to 5432.
When to consult the IANA registry instead
Reach for the IANA Service Name and Transport Protocol Port Number Registry whenever the decision needs exhaustive or time-sensitive evidence. The registry is the authoritative source for every assignment, its aliases, contacts, references, change history, and less common transports such as SCTP and DCCP. It also records which numbers have been returned, transferred, or updated more recently than any curated list can track. The number-space rules above come from RFC 6335.
For learning, compare related clear-text and TLS services such as HTTP and HTTPS, IMAP and IMAPS, or LDAP and LDAPS while remembering that encryption depends on the real service configuration, not on the port. For troubleshooting, treat the ports list as a translation step, then escalate to process inspection, configuration review, and packet capture. For incident response, treat any port number as untrusted until verified against multiple sources on the actual host, because the same number that maps to a benign service in the registry can carry anything once it leaves a controlled environment.