Port 80 vs port 443: HTTP, HTTPS, and what the numbers mean

When you type a URL into your browser, a surprising amount happens before a single byte of the page arrives. Your computer resolves the domain to an IP address, opens a TCP connection to that address, and then specifies a port — a number between 0 and 65535 — that tells the remote server which service to talk to. For plain HTTP that's port 80. For HTTPS it's 443. You never type these numbers because browsers add them automatically. But they matter every time you load a page.

What a port actually is

An IP address gets traffic to the right machine. A port gets it to the right program running on that machine. Think of the IP address as the street address of an office building and the port as the suite number. Both are required to deliver mail to the right desk.

One server can run dozens of services simultaneously — a web server, a mail server, an SSH daemon, a database — each listening on a different port. When a packet arrives, the operating system looks at the port number in the TCP header and routes the packet to whichever program has claimed that port. Without ports, a server couldn't host more than one network service at a time.

Ports 0 through 1023 are called well-known ports. They are assigned by IANA (the Internet Assigned Numbers Authority) and reserved for standardised protocols. Ports 1024 through 49151 are registered ports, used by applications that have claimed them formally but don't require root privileges. Ports 49152 and above are ephemeral — the range your operating system draws from when your browser opens an outbound connection to a web server.

Port 80: the HTTP port

HTTP — HyperText Transfer Protocol — is the language browsers and web servers use to exchange pages. A request goes out, a response comes back, the browser renders it. Simple in concept; the web was built on it.

Port 80 has been HTTP's home since the early 1990s. When you visit http://example.com, your browser connects to port 80 on whatever IP address the domain resolves to, sends a plain-text GET request, and receives a plain-text response. Everything in transit is readable by anyone on the path between you and the server — your ISP, the operators of any intermediate network, anyone running a packet capture on the same Wi-Fi network you're on.

That last part is the problem. HTTP over port 80 offers no confidentiality, no integrity guarantee, and no authentication. You can't verify that the response actually came from the server you think it did, and you can't verify that it hasn't been modified in transit. For delivering a public news article, that may have been acceptable in 1994. For anything involving accounts, payments, or personal information, it never really was.

Port 443: the HTTPS port

HTTPS is HTTP running inside TLS — Transport Layer Security. The protocol for exchanging web pages is identical; what changes is the layer underneath. Before any HTTP request goes out, TLS negotiates a secure channel. Everything after that point is encrypted.

Port 443 was formally assigned to HTTPS in 1994, when Netscape introduced SSL (TLS's predecessor). The number stuck. Today, essentially all meaningful web traffic runs on port 443.

What does "inside TLS" actually mean in practice? The browser and server perform a handshake: they agree on a cipher suite, the server presents a certificate, the browser verifies that the certificate was signed by a certificate authority it trusts, and both sides derive a shared session key. Every byte of the HTTP exchange that follows is encrypted with that key. A packet capture on port 443 shows you the destination IP address and port — but the URL, headers, cookies, and body are all ciphertext.

The certificate does a second job beyond encryption: it proves that the server you're talking to is genuinely the one that controls the domain you requested. Without it, someone who can intercept your traffic could impersonate any site. With a valid certificate, they can't — they'd need the private key that corresponds to the certificate, which stays on the real server.

Why port 80 still exists

If 443 is the secure option, why does 80 exist at all? Mostly for redirection.

When someone types example.com without a scheme, some browsers will try HTTP first — port 80. A well-configured server listens on port 80 specifically to receive that connection and immediately respond with a 301 redirect to the HTTPS version. The browser follows the redirect and all subsequent traffic uses port 443. Port 80 sees exactly one round trip per session: the initial connection and the redirect response.

HTTP Strict Transport Security (HSTS) is the mechanism that eventually eliminates even that single HTTP round trip. Once a browser has visited a site over HTTPS and received an HSTS header, it will refuse to connect to that site on port 80 at all for the specified duration — upgrading to HTTPS before making any network request. For browsers that have seen the HSTS header before, port 80 is effectively unreachable for that domain.

Some older internal tools and local development environments still use port 80 because the overhead of setting up TLS certificates for internal infrastructure wasn't always worth it. That rationale has weakened as tooling like Let's Encrypt made certificates free and nearly instant, but you'll still encounter HTTP-only services on internal networks.

The TLS handshake, briefly

TLS 1.3 — the current version — completes the handshake in a single round trip before any application data flows. Here's what happens:

The client sends a "ClientHello" that includes the TLS version it supports, a list of cipher suites, and a random nonce. The server responds with a "ServerHello" choosing the cipher suite, its certificate chain, and a key exchange value. The client verifies the certificate against its trusted roots, derives the session key from the key exchange parameters, and both sides are ready. The whole thing happens in milliseconds — usually faster than DNS resolution.

TLS 1.2 required two round trips. TLS 1.3 also introduced 0-RTT resumption, which lets a reconnecting client send application data in its very first packet by reusing session material from a previous connection — though this comes with caveats around replay protection.

You can inspect the TLS configuration of any public server — which versions it supports, which cipher suites it advertises, when its certificate expires — with Network Lookup's SSL checker.

Other ports worth knowing

Port 80 and 443 are the ones you encounter most often as a user, but a handful of others are relevant if you're operating servers or diagnosing network issues.

Port 22 — SSH

Secure Shell. Encrypted terminal access to remote servers. If you administer Linux machines, you live in port 22. Because SSH is so universally exposed, it's also the most aggressively scanned port on the internet — automated bots probe it constantly looking for weak credentials. Most administrators either move SSH to a non-standard port, restrict it by source IP, or require key-based authentication instead of passwords.

Port 25 — SMTP

Simple Mail Transfer Protocol — how mail servers communicate with each other when delivering messages. Your mail client almost certainly doesn't use port 25 (it uses 587 or 465 for submission). Port 25 is server-to-server. Residential ISPs block outbound port 25 connections to prevent their networks from being used to send spam.

Port 53 — DNS

DNS queries go here. Both UDP (for most queries) and TCP (for large responses and zone transfers) use port 53. It's one of the few ports that needs to be open outbound on nearly every firewall — without port 53, DNS doesn't resolve, and the internet becomes unreachable by hostname. The DNS record explainer covers what's actually being returned when that port answers.

Port 443 (again) — but also QUIC

HTTP/3 uses QUIC instead of TCP, but it still runs on port 443 — over UDP rather than TCP. A browser that negotiates HTTP/3 will see the same port number in the URL, but the underlying transport protocol is different. This is why firewalls that block UDP/443 can silently break HTTP/3 while appearing to work fine for HTTP/1.1 and HTTP/2.

Port 3306 — MySQL, port 5432 — PostgreSQL

The default ports for the two most common open-source relational databases. These should never be exposed to the public internet — a firewall rule blocking inbound connections to these ports from outside your network is one of the most basic security configurations on a database server.

Port 8080 — alternate HTTP

Commonly used by development servers, proxies, and internal tools that want to run HTTP without claiming the privileged port 80. You'll often see it in local development: http://localhost:8080. It carries no inherent meaning beyond convention, but many tools default to it as a safe alternative to port 80 when running as a non-root user.

How to see which ports are open

On a local machine, ss -tlnp on Linux (or netstat -an on older systems and Windows) shows every TCP port currently listening and which process has claimed it. The output looks like this:

State   Recv-Q  Send-Q  Local Address:Port    Peer Address:Port
LISTEN  0       128     0.0.0.0:22           0.0.0.0:*
LISTEN  0       511     0.0.0.0:80           0.0.0.0:*
LISTEN  0       511     0.0.0.0:443          0.0.0.0:*
LISTEN  0       128     127.0.0.1:5432       0.0.0.0:*

This particular output shows SSH on 22, HTTP and HTTPS on 80 and 443, and PostgreSQL on 5432 — but the database is only listening on the loopback address (127.0.0.1), so nothing from outside the machine can reach it.

For checking ports on a remote server — whether a service is actually reachable from outside — nmap is the standard tool. A simple nmap -p 80,443 example.com will tell you whether those ports are open, closed, or filtered. Just be aware that port scanning someone else's servers without permission is not appropriate; keep it to machines you control.

Network Lookup's HTTP headers checker will show you the response headers a server sends on port 443, including the HSTS header, redirect chains, and whether the server is terminating TLS correctly.

The number is just a convention

Nothing technically forces HTTP to live on port 80 or HTTPS on port 443. You can run an HTTP server on port 9000 or an HTTPS server on port 8443 — people do this all the time in development and internal tooling. The only requirement is that the client knows which port to connect to, which is why you'd write https://example.com:8443 explicitly rather than relying on the default.

The well-known port assignments exist to give clients a sensible default, so that typing a bare hostname in a browser works without additional configuration. The browser knows to try port 80 for HTTP and port 443 for HTTPS because those assignments are standardised, not because the protocol requires it.

Most of the internet's conventions are like this — agreements that became defaults, then became invisible. Ports are one of the older and more stable ones.