Port 80: HTTP

For two decades, port 80 was the front door to the World Wide Web. Type a URL, and your browser knocked on port 80, expecting a web server to answer with HTML, images, whatever you asked for.

Today, port 80 still answers. But mostly it says: "Wrong door. Go to 443."

How Port 80 Became the Default

When Tim Berners-Lee and his colleagues at CERN built the web in the early 1990s, browsers and servers needed to agree on where to meet. The Internet Assigned Numbers Authority designated port 80 for HTTP traffic.

The magic was in what users didn't have to type. "example.com" worked because browsers knew to try port 80 automatically. No one had to remember "example.com:80." This invisible convention let the web spread to people who had no idea what a port was.

Throughout the 1990s and 2000s, port 80 carried the web. Every page load, every form submission, every image—all of it flowed through port 80 using HTTP. The port and the protocol became synonymous with the web itself.

What Happens on Port 80

HTTP defines how browsers ask for things and how servers respond. Your browser opens a TCP connection to port 80, sends a request ("give me /index.html"), and the server sends back the content along with metadata about what it is and how long to cache it.

All of this happens in plaintext. The URL you're visiting, the cookies your browser sends, the page content coming back—none of it is encrypted. Anyone positioned between you and the server can read every byte. For two decades, every URL you typed was a postcard anyone could read.

Port 80 itself is just an address. It's where web servers traditionally listen, waiting for HTTP requests to arrive. The port number routes traffic to the right application; HTTP handles what happens next.

The Shift to Encryption

HTTP's transparency became a liability as the Internet grew up. What worked fine for academic papers and hobbyist pages became dangerous when people started typing passwords and credit card numbers.

HTTPS emerged as the fix—HTTP wrapped in TLS encryption. Initially, only login pages and checkout flows used it. The rest of the web stayed on HTTP because HTTPS required buying certificates, configuring servers, and accepting a small performance penalty.

Then the pressure mounted. High-profile breaches. Privacy advocacy. Google announcing in 2014 that HTTPS would boost search rankings. Browser vendors marking HTTP sites as "Not Secure." Let's Encrypt launching in 2016 and making certificates free.

The result: by 2025, roughly 88% of websites use HTTPS by default, and Chrome users spend over 93% of their browsing time on encrypted pages¹. Port 80 didn't disappear. Its job changed.

Port 80's New Job: Pointing Elsewhere

Today, port 80 exists primarily to redirect. Web servers listen on both port 80 and port 443, but port 80's listener has one job: catch anyone who typed "http://" or no protocol at all, and send them to HTTPS.

The redirect uses HTTP status code 301 (Moved Permanently) or 308 (Permanent Redirect). The response includes a Location header pointing to the HTTPS URL. Your browser follows it automatically. You type "example.com," briefly touch port 80, get redirected, and land on port 443. The whole detour takes milliseconds.

Some sites go further with HSTS (HTTP Strict Transport Security). Once your browser sees an HSTS header from a domain, it remembers. Future visits skip port 80 entirely—the browser internally upgrades "http://" to "https://" before making any network request. Port 80 doesn't even get the redirect request anymore. For browsers that know better, the door has become invisible.

Where Port 80 Still Lives

Despite HTTPS dominance on the public Internet, HTTP and port 80 persist in specific contexts.

Internal networks. Corporate intranets often run internal tools over HTTP. When traffic never leaves a trusted network, encryption can feel like overhead. Documentation wikis, monitoring dashboards, admin interfaces—many still answer on port 80.

Development environments. Local development servers default to HTTP because configuring TLS for "localhost" adds friction to workflows that already have enough friction. Port 8080 (HTTP's common alternate) sees heavy use in dev.

IoT and embedded devices. Configuration interfaces on routers, cameras, and sensors often use HTTP, especially on older or resource-constrained hardware where TLS processing is expensive. This practice is increasingly discouraged but remains common.

Behind load balancers. In some architectures, the load balancer handles TLS termination. Users connect via HTTPS, but the load balancer talks to backend servers over HTTP on a private network. Port 80 traffic exists, but only where outsiders can't see it.

The Risks of Plaintext

HTTP's lack of encryption creates concrete vulnerabilities.

Eavesdropping. Anyone on the network path between you and the server can read HTTP traffic. On public WiFi, that includes everyone else at the coffee shop—and anyone who's compromised the network. Your browsing history, your form submissions, your session cookies—all visible.

Man-in-the-middle attacks. An attacker positioned between browser and server can modify HTTP traffic in transit. Inject scripts. Replace downloads with malware. Change what you see without you knowing.

Modern browsers make these risks hard to ignore. Chrome, Firefox, Safari, and Edge all display "Not Secure" warnings for HTTP sites. The warning intensifies when the page contains password or credit card fields.

For site owners, HTTP means lower search rankings, browser warnings, and potential liability. For users, submitting sensitive information over HTTP is a risk worth avoiding.

Sources