Port Number Reference
Search and inspect common UDP/TCP ports and their standards.
Port Number Reference
| Port | Type | Service | Description |
|---|---|---|---|
| 22 | TCP | SSH | Secure Shell for remote access |
| 80 | TCP | HTTP | Hypertext Transfer Protocol |
| 443 | TCP | HTTPS | Secure Hypertext Transfer Protocol |
| 53 | UDP/TCP | DNS | Domain Name System resolver |
| 21 | TCP | FTP | File Transfer Protocol control channel |
Runs entirely in your browser
This tool executes locally using standard browser APIs (for example window.crypto.getRandomValues or crypto.subtle where applicable). Your input is not transmitted to or stored on a ScriptPulse server. See How Calculations Work.
What This Tool Does
- The Port Number Reference is a searchable lookup for TCP and UDP port numbers and the services conventionally associated with them — the well-known ports (0–1023), registered ports (1024–49151), and notable ports in the dynamic/private range (49152–65535) that have become de facto standards despite being technically unassigned. Every network service (HTTP, SSH, DNS, database servers, and thousands of others) has a conventional port, and remembering which is which is a constant, low-value cognitive load during troubleshooting and configuration.
- This is a reference tool, not a scanner or a live-connectivity checker: it doesn't tell you whether a port is actually open on a specific host, only what a given port number is conventionally used for, and conversely, which conventional port a given service normally uses. That distinction matters — the actual port a service listens on is configurable and the convention is just that, a convention, but knowing the default is essential for reading firewall rules, docker port mappings, and connection strings correctly.
- Coverage spans the IANA-registered well-known and registered port assignments plus commonly-encountered ports that are widely used in practice even without formal IANA registration.
How It Works
- Search by port number to see the service(s) conventionally associated with it, or search by service name to find its conventional port.
- Results distinguish TCP, UDP, or both, since some services use different port conventions per protocol, or use the same number for both.
- Each result includes the port's IANA registration status (well-known, registered, or unassigned-but-conventional) for context on how authoritative the association actually is.
- The reference data is drawn from the IANA Service Name and Transport Protocol Port Number Registry, the authoritative source for official port assignments.
Usage
- Enter a port number or a service name into the search field.
- Review the matching result: protocol (TCP/UDP/both), conventional service, and registration status.
- For port numbers with multiple historical or overlapping associations, review each listed possibility rather than assuming only one applies.
- Use the result to inform firewall rules, connection strings, or as a starting point when investigating unfamiliar traffic.
Examples
- Looking up port 443 and confirming it's the well-known port for HTTPS (HTTP over TLS).
- Looking up 'PostgreSQL' by service name and getting back its conventional port, 5432.
- Looking up port 8080 and finding it's a widely-used but not IANA-well-known alternate HTTP port, common for development servers and proxies.
- Checking port 22 to confirm it's the standard SSH port before deciding whether it's safe to leave open on a public-facing firewall rule.
Real-World Use Cases
- Quickly checking what a specific port number means when reading a firewall rule, security group configuration, or docker-compose port mapping.
- Confirming the correct default port to use when writing a connection string or client configuration for a database, mail server, or other network service.
- Reviewing which ports need to be opened for a new service deployment before configuring firewall rules.
- Cross-referencing an unfamiliar port seen in network traffic logs against its conventional service association as a first investigative step.
Best Practices
- Treat well-known/registered port numbers as strong conventions, not guarantees — always confirm what a specific service is actually configured to listen on in your environment rather than assuming the default.
- When opening firewall rules, document why each port is open and which service it maps to, using this kind of reference as the source, so future audits don't have to reverse-engineer the intent.
- For internal services without a public convention, pick ports from the dynamic/private range (49152–65535) to avoid future collisions with newly-registered well-known services.
- When investigating unfamiliar traffic on a non-standard port, don't assume malicious intent purely from the port number — many legitimate services deliberately run on non-default ports.
Common Mistakes
- Assuming a service is safe or expected purely because it's running on its 'normal' port, without actually verifying what's listening there — port conventions are not enforced by the network, so anything can technically listen on any port.
- Confusing a port being open in a firewall rule with a service actually running and listening on it — they're independent facts that both need to be true for a connection to succeed.
- Forgetting that some services use different ports for TCP versus UDP (DNS is the classic example: port 53 for both, but with different behavior — TCP for zone transfers and large responses, UDP for typical queries).
- Hardcoding an assumed default port in application code instead of making it configurable, causing avoidable breakage when a deployment needs a non-default port.
Limitations
- This is a reference lookup for conventional port assignments, not a live port scanner — it cannot tell you whether a specific port is actually open, filtered, or in use on any real host.
- Coverage prioritizes IANA-registered and widely-recognized conventional ports; extremely obscure or purely internal/proprietary port usages by specific vendors may not be represented.
- Port conventions can and do get reused or reassigned over long timeframes by IANA; always treat a lookup as the current common convention, not an immutable guarantee.
Technical Reference Guide
- TCP and UDP port number ranges (well-known, registered, dynamic/private) are defined by RFC 6335, which also governs the IANA registration process for new port assignments.
- The authoritative, continuously-updated source of official port assignments is the IANA Service Name and Transport Protocol Port Number Registry.
- TCP itself is defined by RFC 9293; UDP is defined by RFC 768 — both use the same 16-bit port number space but maintain independent port assignments per protocol.
FAQ
What's the difference between well-known, registered, and dynamic ports?
Well-known ports (0–1023) require IANA registration and are historically reserved for core internet services; registered ports (1024–49151) are also IANA-registered but for a broader range of applications; dynamic/private ports (49152–65535) are unregistered and intended for temporary or private use, such as ephemeral client-side connections.
Can any service run on any port?
Technically yes — port numbers are a convention, not an enforced restriction. A web server can be configured to listen on port 9999 instead of 80 or 443; clients just need to be told to connect there instead of assuming the default.
Why does DNS use both TCP and UDP on port 53?
Most DNS queries and responses are small enough to use UDP for speed and lower overhead; TCP is used as a fallback for responses too large for a single UDP packet, and specifically for zone transfers between DNS servers.
Is it safe to assume traffic on port 443 is HTTPS?
It's a strong convention but not a guarantee — any protocol can technically be configured to run on port 443. For actual verification, inspect the traffic itself (e.g. checking for a valid TLS handshake) rather than relying on the port number alone.
How do I pick a port for a new internal service?
Choose from the dynamic/private range (49152–65535) to minimize the chance of colliding with a current or future well-known or registered port assignment.
Does this tool check whether a port is actually open on my server?
No — it's a reference for conventional port-to-service associations only. To check whether a specific port is actually open and reachable, use a dedicated port-scanning or connectivity-testing tool against the real host.
Part of this Developer Hub
This utility is part of our comprehensive Networking & Infrastructure topic workspace.
Explore foundational guidelines, technical specifications, and other interactive utilities related to this workflow.
Related Tools
Explore related utilities inside the Network Operations Lab workshop for complementary engineering workflows.
View all Network Operations Lab tools