What does a browser do after we submit a URL?

Eddie Knight
5 min readSep 21, 2022

What’s happening between our browser request and the call to a DNS server?

This is a deep dive to answer the question above, as part of a larger question: What happens when you type “google.com” into the browser and press enter?

In a previous article we explored how every button press we make will have the same sequence of events: the keyboard will translate our analog circuit into a digital signal it’ll send an interrupt request to the CPU, the CPU will translate the request using the bios instructions, drivers will activate the logic in your operating systems kernel, and your kernel will pass along the signal to the browsers input listeners.

For us, the most significant listener on the browser is after we type “google.com” and press the enter key. That’s our entry point here, and we’ll wrap up this article once our browser begins waiting for a response from an internet resource.

After we press the enter key, the browser will take one last look at what we typed in before it decides what to.

The first thing it’ll check is whether we’ve provided a protocol such as HTTP or HTTPS which would make its life easier, because then it wouldn’t need to guess at our intent.

We didn’t provide a protocol, however, so the browser is stuck, guessing.

The guesswork done by the browser’s search engine starts by looking at what we typed in to find out whether it fits the recognizing path for a URL.

URL stands for Uniform Resource Locator and when it comes to the U and the URL, it’s a lot like an address, but for the internet, just like a street address, a URL has a specific uniform format that must be adhered to.

If the text we gave our browser matches that format it will assume that we’re trying to reach the address.

If our input didn’t match the URL format, our browser would pass us along to the default search engine to process the request.

Our entry of google.com does match the uniform format so that won’t happen to our request. Instead, the browser will apply a filter to ensure that no special characters are being used.

This is called Punycode.

This filter won’t modify our request though since we didn’t have anything like spaces in our text. Now that the browser knows that we’re requesting a URL and it’s filtered the text to avoid any unknown characters, the browser needs to figure out which protocol to use because we left it guessing.

So the browser’s going to check it’s built in HSTS list.

This stands for HTTP strict transport security and it’s a protocol that tells browsers they cannot continue to load that page without certain precautions to prevent malicious activity.

If our browser has been told in the past, the website requires this level of protection, it’ll be added to its HSTS list to save time redirecting and asking that question in the future.

Modern browsers, such as chromium will default to using HTTPS.

At this point, the browser has the protocol information we neglected to provide, and it’s almost ready to reach out to the internet, but first the browser will make one last check to try to save time. Earlier we mentioned that the URL is similar to a street address in that it follows a specific uniform format.

That analogy is somewhat misleading however, because a URL by itself is not the true internet address of our target destination. A URL such as google.com is also known as a domain.

Domains are like nicknames that point to a real location.

If we wanted to take our postal example further, we could say that the domain, google.com is equivalent to you posting a letter in the United States addressed to the white house.

Postal workers will often do you a courtesy of sending your letter along to 1600 Pennsylvania avenue in Washington, DC, which is the real physical address for the white house.

In the case of web domains, it is the Domain Name System or DNS that does the forwarding for us. We need that DNS information so that it can tell the browser where to send its request.

The first place the browser will look is its own DNS cash to save time if we’re visiting a site that we’ve gone to previously, but if the browser doesn’t have the domain cash, it will move on to your local operating system to find out whether you’ve set up your system with a custom route for that domain.

A host file on your computer can hold a list of host names that the browser will use prior to checking other sources. If neither the browser or our local system have a listing for this domain, then our computer will reach out to its network to find the necessary information.

Before we can get that DNS information, our machine needs to communicate to the router using the Address Resolution Protocol to communicate with the local network. The ARP broadcast will contain the MAC and IP address of the sending machine, and the same information about the target we’re trying to reach.

On a more complex network, we may encounter a Hub or a Switch, which both will engage in different steps to pass the ARP request to our router. Once the router receives the broadcast, its own software will process the request and send an ARP reply containing the IP address for the configured DNS server or gateway.

This DNS server may belong to your employer, your internet service provider, or you may have configured it to a third party such as Google’s DNS.

Regardless of which authority provided the domain name resolution, at this point our machine will have an IP address to target. For our situation, we’ll assume that the DNS has found the proper address for us to reach Google as we intend to.

Now that our browser has the IP address of our target DNS server or gateway, it will need to open a socket on our local machine that it can use to establish an outgoing connection.

Our operating system contains a library full of program function and one of those functions will allow the browser to open the socket in situations like this.

The browser will pass necessary information to the system library function… Most importantly the IP address and the port number to reach out to.

Keep reading the next article to find out about port numbers, or jump straight to reading about how the browser uses DNS and IP.

If you want to see more articles like this, please hit the “like” button (or hold it down!) so I know to create more content like this in the future.

--

--