What Happens When You Open a Web Page: HTTP and HTTPS

You type an address, press Enter, and a page appears. The wait is usually less than a second, yet a surprising amount of coordination happens in that time. Your browser finds a server, sets up a connection, often agrees on secret keys, asks for a file, receives it, and then collects the other files that make the page complete.

This entry walks through that sequence in order, with a focus on the two protocols at its center: HTTP and HTTPS. It assumes you know the basics from how the internet works. The name lookup step is mentioned only briefly, because what DNS is covers it in full.

Reading the address and mapping the journey

Everything starts with a URL (uniform resource locator), the full address of a resource on the web. Take this example:

https://www.example.com/guides/start.html?lang=en

The browser breaks the URL into these pieces because each one drives a different step. The scheme decides how to connect, the host decides where to connect, and the path decides what to ask for. If you type only a name, the browser fills in a scheme for you, usually the protected one when the site supports it.

The journey in order

Here is the full sequence at a glance. Later sections explain each step.

1. The browser checks its cache for a saved copy of the page.
2. It looks up the server's IP address from the host name.
3. It opens a connection to that address.
4. For HTTPS, it and the server perform a handshake to protect the connection.
5. The browser sends an HTTP request.
6. The server sends back an HTTP response.
7. The browser reads the response and requests every extra file it needs.
8. It assembles and draws the page.

Finding the server and connecting

The lookup

A browser cannot send a request to a name. It needs a number. So it asks the Domain Name System to turn www.example.com into an IP address. If the answer was saved recently, this step is skipped. The mechanics are covered in the DNS entry, so they are not repeated here.

Opening the connection

HTTP needs a dependable channel, so it normally runs on top of TCP, a protocol that numbers data, checks that it arrived and resends what was lost. Before any web data moves, the browser and server exchange a few short messages to open that channel. Each server listens on numbered doors called ports. By convention, plain HTTP uses port 80 and HTTPS uses port 443, and the browser picks the right one from the scheme.

Newer versions of HTTP can use a different transport, called QUIC, which is built on a protocol named UDP. The web page you see is the same. Only the delivery underneath changes.

HTTPS: protecting the connection

Plain HTTP sends text that anyone along the route could read or alter. HTTPS is HTTP carried inside a protected channel built with TLS (Transport Layer Security). The standard describing TLS lists three things it provides:

• Authentication. The browser can check that it is talking to the real server for that name.
• Confidentiality. Only the two ends can read the data in transit.
• Integrity. Any change to the data on the way can be detected.

The handshake in plain words

When the page uses HTTPS, the browser and server first run a handshake:

1. The browser says which protection methods it supports.
2. The server picks one and sends its certificate, a digital document that ties the site's name to a key it controls. A certificate is signed by an organization, called a certificate authority, that browsers already trust.
3. The browser checks the signature, the name and the dates on the certificate.
4. Both sides use cryptography to agree on fresh secret keys, without ever sending those keys openly.
5. From then on, everything is scrambled with those keys.

If the certificate is wrong, expired or issued for a different name, the browser shows a warning page. Take that warning seriously.

What HTTPS does not tell you

The padlock means the connection is protected and the server proved its identity for that name. It does not mean the site is honest or safe. A fraudulent site can also have a valid certificate for its own name. Judge the site by its address and what it asks of you, as you would for any message you receive.

The request and the response

HTTP is a simple conversation made of messages. The browser, acting as the client, always starts. It sends a request, and the server answers with one response.

A basic request looks like this:

GET /guides/start.html HTTP/1.1
Host: www.example.com
Accept: text/html

The first line holds the method (GET means "give me this"), the path and the protocol version. The following lines are headers, extra facts such as which site is wanted and what kind of content the browser accepts. Another common method is POST, used to send data to the server, for example when you submit a form.

The response begins with a status and has headers and a body:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8

<!doctype html>
<html> ... the page ... </html>

Status codes

The three-digit number tells the browser how things went. The first digit gives the group.

HTTP is stateless: each request is separate, and the server does not automatically remember the last one. Sites that need memory, such as a shopping basket or a login, add it with small saved pieces of data called cookies.

From files to a finished page

The first response is usually an HTML file, a text description of the page's structure. As the browser reads it, it discovers more files it needs: style sheets, scripts, fonts and images. Each one is fetched with its own request, often to the same server and sometimes to others. Many requests can share one connection, which saves time.

The browser then combines the pieces. It builds a model of the page from the HTML, applies the styles to decide how everything looks, runs scripts that may change the page, and finally paints the result on your screen. This is why a page can appear in stages, with text first and pictures a moment later.

To avoid repeating work, browsers cache files, keeping copies for reuse according to rules the server sends in its headers. Opening the same site a second time is usually faster for this reason.

When something goes wrong

Knowing the order helps you place a failure:

Common mistakes

• Believing the padlock proves a site is trustworthy. It proves the connection is protected, nothing more.
• Typing passwords on plain HTTP pages. Without protection, anyone on the path could read them.
• Thinking HTTP and HTML are the same. HTTP is the delivery protocol. HTML is a file format that describes a page.
• Ignoring certificate warnings. Clicking through can expose you to someone pretending to be the site.
• Assuming a 404 means the whole site is down. It means the server answered and has nothing at that path.

FAQ

What is the difference between HTTP and HTTPS?

HTTPS is HTTP with a protective layer (TLS) around it. The messages are the same, but in HTTPS they are scrambled in transit and the server proves who it is.

Does HTTPS hide which sites I visit?

Not entirely. The content of your requests is protected, but parts of the connection, such as the server's address, are still visible along the route.

Why does the first visit take longer than the second?

On the first visit the browser must look up the address, open the connection and download every file. Later it can reuse cached answers and files.

What is a GET request?

It is the standard way for a browser to ask for a resource. It only asks for data, and it should not change anything on the server.

Where can I read more?

See the Computing and Networks area. Reading what an IP address is first makes the connection step clearer.