A common port number is a 16-bit transport identifier from 0 to 65535 that IANA records for specific TCP and UDP services and that operators encounter frequently enough to be worth memorizing. In practice, fewer than a hundred such numbers carry most real network traffic — HTTP on 80, HTTPS on 443, SSH on 22, DNS on 53, SMTP on 25, plus a tight cluster of remote-access, database, container, messaging, and printing services. That is why a focused, curated lookup covers the vast majority of day-to-day troubleshooting and configuration questions, even though the official registry records thousands of assignments. When you see an unfamiliar number in a log, firewall rule, or scan output, translating it to a likely service is usually the first step before any deeper investigation. Knowing the registered name narrows the candidate processes, the configuration file that matters, and the kind of traffic to expect on the wire.
The problem with raw registries is scale and noise. The full IANA Service Name and Transport Protocol Port Number Registry lists thousands of assignments, aliases, references, and change history entries that slow down a quick lookup. Developers and operators need a smaller, opinionated table they can keep on one screen, search instantly, and copy into a ticket without scrolling past half a dozen deprecated or rarely seen entries. That is the design intent behind a curated ports reference: stable, focused, and aligned with operational use rather than registry completeness.
What "Common Port Numbers" Actually Means
IANA divides the 16-bit port space into three registered ranges, defined in RFC 6335 and visible on the official registry. The table below summarizes those ranges and the role each plays in real deployments.
| Range | Numeric span | Typical role |
|---|---|---|
| System Ports | 0 – 1023 | Assigned services that historically required root or administrator privileges on most operating systems |
| User Ports | 1024 – 49151 | Registered services from IANA, vendor conventions, and applications that do not need elevated privileges |
| Dynamic / Private Ports | 49152 – 65535 | Ephemeral ports used by clients and by services running on non-standard ports; not centrally assigned |
"Common port numbers" almost always refers to entries drawn from the lower two ranges. Web servers, mail transfer agents, name servers, database daemons, container runtimes, remote shells, and printing services all fall inside 0 to 49151. The Dynamic range is intentionally omitted from curated lists because the numbers are not assigned to a service and can be reused by any program on the host at any time.
How to Look Up a Common Port Number
The fastest way to translate a number into a service, or a service into a number, is the Common Network Ports List. The table is sortable, searchable, and filterable, so you can move from a host-side observation to a likely daemon in a few keystrokes.
- Enter a port number, service name, product term, or short description in the search field. For example, typing 443 returns HTTPS, typing PostgreSQL returns 5432, and typing mail returns SMTP, POP3, IMAP, message submission, and their TLS variants.
- Optionally filter the visible rows by TCP or UDP using the protocol control. Use TCP for most web, mail, file transfer, and database lookups; use UDP when you specifically want DNS, SNMP, syslog, or other connectionless protocols.
- Optionally filter by service category to isolate databases, web services, network infrastructure, remote access, printing, or another supported group without changing the underlying reference data.
- Review the matching registration hints shown in the table: one numeric port, the selected IANA service name, one or more relevant transport protocols, a short plain-language description, and the category used by the filter.
- Copy the visible rows as tab-separated text when you need a reference for a ticket, runbook, study sheet, or configuration review. Nothing leaves the browser; the export is generated locally from the rows you currently see.
Because the search is case-insensitive and runs across the port number, service name, description, and category fields simultaneously, you can mix strategies mid-task. A query that begins as 8080 can be refined to "8080 web" or "8080 proxy" as your context narrows, without restarting the lookup.
How the Search and Filters Work
Under the hood, the curated table stores one sorted row per displayed port, and every row has been checked against the IANA Service Name and Transport Protocol Port Number Registry. The search function matches your text against the numeric port, the selected service name, the description, and the category label, then immediately rewrites the visible rows to reflect only the matches. There is no server round-trip and no cache to invalidate: typing and filtering both update the table inline.
The protocol filter distinguishes TCP from UDP where that distinction is operationally meaningful. DNS appears with both protocols because name resolution legitimately uses either, depending on the query size and the resolver implementation, while HTTPS is shown with TCP only because that is the path realistic web traffic follows in production. The category filter is a fast narrowing tool: when you want every database in the table, the filter removes web, mail, and container rows instantly without altering the underlying data set.
One expected limitation is intentional: the table holds roughly forty ports rather than the full IANA registry. That scope choice keeps the screen readable and the search fast, and it matches what most developers and operators actually need during a single troubleshooting session. For exhaustive assignments, second registrations, SCTP or DCCP entries, aliases, contacts, and change history, follow the link to the IANA registry above and use it as the authoritative tie-breaker.
Reading the IANA Registration Context
Even a short port carries a small amount of registry context worth understanding. IANA explicitly warns that "assignment does not endorse an application and does not prove observed traffic is good." Registration is a hint, not a verdict: a number on the list tells you what an application most likely is, not what the application running on the host you are looking at actually does.
RFC 6335 expands on that point by separating the number space into the three ranges above and by describing what each range means. System Ports are tied to historical privilege expectations, User Ports are open to vendor and community proposals, and Dynamic Ports exist so that the operating system and applications can pick ephemeral identifiers without conflicting with anything assigned. When you see a four-digit number above 49151 in a log, treat it as opaque and follow the connection back to a process rather than a service name.
The descriptions in the curated table are deliberately shortened to make scanning easier, but they do not override the registry wording. If a description here conflicts with one in IANA, treat IANA as authoritative. The common ports list is built for quick lookup; the registry is built for decisions that need full context, dated references, and complete assignment history.
Copying Rows for Tickets and Runbooks
The copy action only exports the rows you currently see after the search and filters are applied. That feature is what makes the tool useful for documentation: you can search for "mail", switch the protocol filter to TCP, and copy a five-row reference covering SMTP, POP3, IMAP, message submission, and a TLS variant in tab-separated form. Pasting that block into a ticket, runbook, or Markdown study sheet preserves alignment, since tabs survive most plain-text intake points.
The data flow stays inside the browser. No query is sent to a backend service, no copied row is logged, and no telemetry is generated from your search terms. For sensitive environments, that local-only behavior matters as much as the lookup speed: you can translate a port to a service on a workstation that is otherwise air-gapped, as long as the page itself was loaded.
When a Port Number Is Not Enough
Port-based identification has three well-known failure modes. First, a server can listen on an unusual port — HTTPS on 8443, PostgreSQL on 5433, SSH on 2222 — to dodge conflicts with another daemon, and the registered number does nothing to disclose that move. Second, several registered names can share one number, so 1194 may be OpenVPN, a vendor management agent, or anything else the host operator chose. Third, a packet using a registered number may belong to a different program entirely; nothing on the wire forces the application to honor the registry.
Concretely, that means the port reference supports translation, not conclusion. Use it to move from "what is 636" to "LDAPS, the LDAP over TLS variant" before checking the actual endpoint with platform-native tools, service configuration, logs, and network policy. For firewall decisions, the answer must include direction, source, destination, protocol, authentication, encryption, business owner, and least-privilege scope — none of which can be inferred from a port number alone. If you need a deeper discussion of the firewall question specifically, see Can a Common Ports List Be Used as a Firewall Allowlist?, and for a broader catalog of typical services see List of Most Common Network Ports: TCP and UDP.
For learning, the curated table is a good place to compare clear-text and TLS pairs: HTTP and HTTPS, IMAP and IMAPS, LDAP and LDAPS. Just remember that the encryption status depends on the real service configuration, not on the chosen port. A daemon configured for STARTTLS still uses the same registered number as its plain variant, and a TLS-only service on a non-standard port still speaks its protocol regardless of whether the port appears in the table.
When the lookup is complete, the last step is to verify the live endpoint: a process listing, a listening-socket dump, a configuration review, or a packet capture. Port numbers are useful first questions. They are not the final answer.