Five of the most frequently encountered network ports are 80 (HTTP), 443 (HTTPS), 22 (SSH), 25 (SMTP), and 53 (DNS). Each of these ports is associated with a specific registered service that uses either TCP or UDP as its transport protocol. Port 80 carries unencrypted web traffic over TCP, port 443 carries the same kind of traffic but with TLS encryption, port 22 is the default for SSH remote access over TCP, port 25 handles SMTP mail submission between servers over TCP, and port 53 resolves domain names through DNS using both TCP and UDP. Knowing these five numbers, the services behind them, and the protocols they use is a practical starting point for studying networking, reading firewall logs, configuring local services, and recognizing traffic on a packet capture. The numbers themselves are hints rather than guarantees, which is why each one also comes with caveats about how and where it actually appears in real systems.
Why these five ports are the typical starting point
When developers, sysadmins, and students first encounter network ports, the same handful of numbers tends to show up again and again: HTTP on 80, HTTPS on 443, SSH on 22, SMTP on 25, and DNS on 53. They appear in firewall rules, exam questions, vendor documentation, and troubleshooting guides. Each one represents a service that has been formally registered with the IANA Service Name and Transport Protocol Port Number Registry, which is the authoritative source for the assignments described in RFC 6335. Picking these five gives a quick way to recognize the most common types of traffic on a typical host: web, secure remote shell, mail transfer, and name resolution. Once you can read those five quickly, additional ports such as 21 (FTP), 23 (Telnet), 110 (POP3), 143 (IMAP), 389 (LDAP), 636 (LDAPS), 3306 (MySQL), 5432 (PostgreSQL), and 3389 (RDP) feel like natural extensions rather than brand-new vocabulary.
The five common ports at a glance
The table below summarizes the five most frequently referenced ports, the registered service name, the typical transport protocol, and a short description of what the port is normally used for. These rows are taken from the kind of curated reference you can open in the Common Network Ports List, which keeps them together with the rest of the common operational set.
| Port | Service | Protocol | Typical use |
|---|---|---|---|
| 22 | SSH | TCP | Encrypted remote shell, file transfer (SCP, SFTP), and port forwarding |
| 25 | SMTP | TCP | Server-to-server email transfer; also used by unauthenticated mail submission |
| 53 | DNS | TCP, UDP | Domain name resolution; UDP for ordinary queries, TCP for large responses and zone transfers |
| 80 | HTTP | TCP | Unencrypted web traffic, often used for redirects to HTTPS |
| 443 | HTTPS | TCP | TLS-encrypted web traffic, the default for modern browsers and APIs |
Notice how the protocol column is not uniform. Most web, mail, and remote access traffic is TCP because those services need an ordered, reliable stream. DNS uses both TCP and UDP because most queries are small enough for a single UDP datagram, while larger responses, TCP fallbacks, and zone transfers need the guarantees of TCP. A "common ports" reference that only listed TCP, or that pretended DNS was UDP only, would give an incomplete picture of what actually happens on the wire.
How to look up a port in the Common Network Ports List
The Common Network Ports List is built as a quick local reference rather than as a full registry browser. You do not need to upload anything, and nothing you type or copy leaves the page. The following steps walk through the typical lookup workflow.
- Open the Common Network Ports List in your browser and locate the search field at the top of the table.
- Type a port number, service name, product term, or short description. The search is case-insensitive and matches across the port number, the service name, the description, and the category column. For example, entering "443" returns HTTPS, while entering "PostgreSQL" returns 5432.
- If you want to narrow the visible rows further, use the protocol filter to keep only TCP entries or only UDP entries, and use the category filter to isolate groups such as web, mail, databases, network infrastructure, or remote access.
- Read the description column to confirm that the service you found actually matches the traffic or configuration you are checking. A matching port number does not by itself prove which program is listening on the host.
- When you need the rows for a ticket, runbook, study sheet, or configuration review, use the copy action to export only the currently visible rows as tab-separated text. The hidden rows are not included, so the filters you have set become part of what you paste.
This last step is useful when you want a focused excerpt, such as "all web ports" or "only database ports," without going through the entire 40-row table by hand. Pasting tab-separated text into a spreadsheet, Markdown table, or ticket template keeps the columns aligned and reduces the chance of transcription errors.
What each column in the reference means
The table deliberately includes one row per displayed port, so each column has a specific role. The port column is the numeric identifier from 0 to 65535. The service column shows the registered IANA service name, which is the short label chosen by IANA for that assignment. The protocol column lists the transport protocol or protocols that are commonly used for that service in this curated view; for example, DNS shows both TCP and UDP, while HTTPS shows TCP. The description column gives a short plain-language summary of the practical role of the port, intentionally shortened so you can scan it quickly. The category column groups related services, such as "web" for HTTP and HTTPS or "mail" for SMTP, POP3, and IMAP, and is the same value used by the category filter.
Ports in the reference are sorted numerically and are unique within the curated set, so you will not see two rows for the same number with different services. If you have seen a port used for two different purposes in practice, that is one of the reasons the underlying IANA registry exists; the curated view trades exhaustiveness for readability.
When a port number does not tell the whole story
Registered port numbers are hints about traffic, not proof of identity. IANA itself warns that an assignment does not endorse an application and does not prove that observed traffic is good. Three situations make this important. First, a server can listen on a non-standard port: an HTTPS service on 8443 is still HTTPS, even though 443 is the registered number. Second, several registered names may exist for a single port, so a match against one service name does not exclude another. Third, a packet using a registered number may belong to an unrelated program, especially on a shared host where multiple services are configured to listen on the same interface or where port translation has been applied. Treating the list as a translation aid rather than an authentication mechanism keeps expectations in line with how networks actually behave.
Using the list for study, troubleshooting, and firewall review
The same lookup has different consequences depending on the task. For study, comparing clear-text and TLS variants is one of the easiest ways to internalize the difference between protocols like HTTP and HTTPS, IMAP and IMAPS, or LDAP and LDAPS, while remembering that encryption in practice depends on the actual service configuration, not just the port. For troubleshooting, the list is a translation step: it converts an unfamiliar number into a likely service so you can decide which platform-native tool, configuration file, or log to check next. For firewall work, a port lookup is only the starting line; a real policy still needs a verified business purpose, direction, source and destination addresses, protocol, authentication, encryption, business owner, and a least-privilege scope.
When the curated 40-port set does not contain the number you need, the next step is to consult the IANA Service Name and Transport Protocol Port Number Registry, which is the source of every assignment described above. That registry covers all three ranges defined in RFC 6335 (System Ports 0 to 1023, User Ports 1024 to 49151, and Dynamic or Private Ports 49152 to 65535) and includes alternate registrations, contacts, references, and history that no compact table can show. The Common Network Ports List is meant to get you to the right neighborhood quickly; the IANA registry confirms what is actually on the deed.