Common Ports Explained: Standard Ports, Ranges, TCP vs. UDP

A port is a 16-bit number (0-65535) that, paired with an IP address, addresses one specific service on a host — the IP address gets a connection to the right machine, the port number gets it to the right program listening on that machine. A single server can run a web server on 80, a mail server on 25, and a database on 5432 at the same time, all reachable at the same IP address, because the port number is what tells the operating system which of those to hand the connection to.

IANA splits the full 0-65535 range into three bands. Which band a port falls in says something real about it — whether it needs elevated privileges to bind, whether it's formally assigned to a specific service at all, and whether it's meant to be a fixed destination or a temporary, throwaway number.

0-1023 — Well-Known Ports (System Ports)

Assigned by IANA to standard, long-established services — HTTP, SSH, DNS, and the like. On Unix-like systems, binding to any port in this range has historically required root/administrator privileges, which is exactly why a web server normally runs as root (or with a capability grant) just to listen on port 80, then often drops to an unprivileged user for everything else. This is the range worth actually memorizing — the same handful of numbers show up constantly.

1024-49151 — Registered Ports

Also assigned by IANA on request, to a specific application or vendor, but binding to one doesn't require elevated privileges on any mainstream OS — this is the range application developers actually get to pick a default port from. Most database engines, admin protocols, and self-hosted app defaults live here.

49152-65535 — Dynamic, Private, or Ephemeral Ports

Never assigned to any service. This range exists for two purposes: the temporary source port your own machine picks for an outgoing connection (every request your browser makes uses a different, essentially random port from this range as its return address), and a safe range to pick for a private or test service with zero risk of colliding with a registered one. Nothing in this range is standard — a service running on 54321 tells you nothing about what it is.

The exact ephemeral range an OS actually draws from varies slightly and isn't always the full IANA band:

TCP vs. UDP

Both sit at the same layer, on top of IP, and both use the same port-number system above — but they make opposite trade-offs, and the choice between them is baked into each service's design, not something a client or server picks per-connection.

The pattern behind that last row: TCP is the right choice whenever correctness matters more than speed — a web page with a missing byte is broken, so it's worth the extra round trips to retransmit it. UDP is the right choice whenever a stale retransmission is actively worse than just dropping the data — a video call that pauses to redeliver a frame from two seconds ago isn't an improvement over just skipping it and moving on.

A few services genuinely use both, for different parts of the same job. DNS queries almost always run over UDP for speed, but fall back to TCP when a response is too large for one UDP packet, and zone transfers between DNS servers use TCP exclusively since a lost record there is a real problem, not a redrawn frame. SIP, the VoIP call-setup protocol, is defined for both — the actual voice audio still travels separately over UDP (via RTP) even on a TCP-signaled call, because audio is exactly the "a late packet is worse than a lost one" case above.

Checking Whether a Port Is Actually Open

Knowing which port a service should use is only half the picture — the other half is whether that port is actually reachable from outside the network, which a firewall, security group, or NAT rule can silently block regardless of whether the service itself is running fine. That's a separate question this guide doesn't answer on its own.

Use the Port Checker to test any port from these tables — or any custom one — from an external vantage point, and see the difference between open, closed, and filtered results.

Frequently Asked Questions

Do I need root/admin privileges to run a server on port 80?

On Unix-like systems, historically yes — anything under 1024 requires elevated privileges to bind. In practice, most deployments avoid running an application server as root at all: a reverse proxy (nginx, Caddy, a cloud load balancer) binds 80/443 instead and forwards to the actual app on an unprivileged port like 3000 or 8080, or the OS grants the specific binary a narrow capability (setcap on Linux) instead of full root.

What's the practical difference between "well-known" and "registered" ports?

Both are formally assigned by IANA to a specific service, so a number in either range should mean the same thing everywhere. The practical difference is the privilege requirement: binding under 1024 needs elevated privileges on most systems, binding above it doesn't — which is exactly why almost every self-hosted app's default port (Redis' 6379, Postgres' 5432, Grafana's 3000) sits comfortably above 1024.

Why does my browser use a different port every time I load a page?

The server's port (443 for HTTPS) stays fixed — that's the whole point of a well-known port, so clients know where to find it. Your browser's side of the connection is a temporary, ephemeral port picked fresh from the dynamic range for that one connection, so your OS can tell multiple simultaneous connections apart and route each reply back to the right one. Close the tab and reopen the same site, and you'll very likely get a different ephemeral port, while the server's port never changes.

Can two services share the same port number?

Not on the same IP address and protocol at the same time — that combination is what makes a listening socket unique. Two different processes can't both bind TCP port 443 on the same IP simultaneously; the second attempt fails. What can coexist is TCP and UDP on the same number (they're tracked separately, which is exactly why DNS can use port 53 on both), or the same port on different IP addresses on a multi-homed server.

Which port should I check first if a site won't load?

443 (HTTPS) first, then 80 — a modern site almost always serves over HTTPS with an HTTP-to-HTTPS redirect on 80, so if 443 is closed or filtered from the outside, that alone typically explains the whole outage regardless of whether the server itself is healthy.