What Happens When You Type a URL in the Browser?

You type:

https://example.com

into your browser and press Enter.

A few seconds later, the webpage appears.

It feels like the browser simply opened the website.

But behind that simple action, several things happened involving the browser, DNS, IP addresses, HTTP, servers, and browser rendering.

So what actually happens between pressing Enter and seeing the webpage?

Let's follow the journey.

The Big Picture

At a high level, the journey looks like this:

You type a URL
      ↓
    Browser
      ↓
     DNS
      ↓
  IP Address
      ↓
  Connection
      ↓
 HTTP Request
      ↓
    Server
      ↓
HTTP Response
      ↓
 HTML / CSS / JS
      ↓
Browser Rendering
      ↓
  Web Page

Now let's understand what happens at each step.

1. The Browser Starts With the URL

A URL (Uniform Resource Locator) is a string that identifies the location of a resource on the internet and tells the browser how to access it.

For example:

https://example.com/products?id=10

It contains different parts:

https://example.com/products?id=10
   ↓          ↓          ↓        ↓
Protocol    Domain     Path     Query

The https part tells the browser to use secure HTTP communication.

example.com is the domain name.

/products is the path.

?id=10 is a query parameter that provides additional information to the server.

So when you type a URL, you're basically giving the browser an address and instructions for accessing a resource.

But there's a problem.

The browser can't communicate across the internet using just the human-friendly name example.com.

It needs an IP address.

2. DNS Finds the IP Address

This is where DNS (Domain Name System) comes in.

DNS is a system that helps translate domain names into IP addresses.

Think of it like the internet's phonebook.

You remember:

example.com

But the network needs an IP address to identify the destination.

So the simplified process looks like:

example.com
     ↓
    DNS
     ↓
IP Address

An IPv4 address might look like:

93.184.216.34

The actual address returned depends on the website and its DNS configuration.

The browser or operating system may already have the answer cached, so a DNS lookup isn't always required from scratch.

But conceptually, the important idea is:

DNS helps the browser find the IP address associated with the domain name.

Now the browser knows where it needs to communicate.

3. The Browser Connects to the Server

Once the browser knows the destination IP address, it needs to establish a suitable network connection.

A server is a computer or software system that provides resources or services to clients.

In our case:

Browser → Client
Server  → Provides the requested resources

For many traditional web connections, HTTP/1.1 and HTTP/2 use TCP (Transmission Control Protocol) as the transport protocol.

TCP helps provide reliable and ordered delivery of data between applications.

You don't need to memorize the TCP handshake to understand this article.

The simple idea is:

The browser needs a network connection through which it can communicate with the server.

For modern HTTP/3 connections, the transport works differently because HTTP/3 uses QUIC instead of TCP.

For now, the important thing is understanding that the browser needs a suitable connection before exchanging web data.

4. HTTPS Makes the Communication Secure

Our URL starts with:

https://

The S in HTTPS stands for Secure.

HTTPS uses TLS (Transport Layer Security) to protect HTTP communication.

TLS helps provide:

• Encryption
• Authentication
• Integrity

In simple terms, TLS helps protect the communication between your browser and the server and helps the browser verify the server's identity.

A simplified flow is:

Browser
   ↓
Network Connection
   ↓
TLS
   ↓
Secure Communication

Now the browser is ready to communicate with the server securely.

5. The Browser Sends an HTTP Request

Now comes HTTP (Hypertext Transfer Protocol).

HTTP is a protocol that allows clients and servers to communicate on the web.

The browser sends an HTTP request to the server.

For example:

GET /products?id=10 HTTP/1.1
Host: example.com

The browser is essentially saying:

"I want the /products?id=10 resource from example.com."

GET is an HTTP method commonly used when requesting a resource.

An HTTP request can contain things such as:

• Method
• Path
• Headers
• Request body, when needed

For our example, the browser is mainly asking the server to retrieve something.

6. The Server Processes the Request

The server receives the request.

Now it has to figure out what to do with it.

For example:

GET /products?id=10

The server might:

1. Understand the requested path.
2. Read the query parameter.
3. Run application logic.
4. Query a database.
5. Prepare the required data.
6. Create a response.

For a simple website, the server might just return an HTML file.

For a dynamic application, there could be much more happening:

Browser
   ↓
HTTP Request
   ↓
Server
   ↓
Application
   ↓
Database
   ↓
Application
   ↓
Server

This is one reason why a simple button click in a web application can trigger many operations behind the scenes.

7. The Server Sends an HTTP Response

After processing the request, the server sends an HTTP response back to the browser.

A response usually contains:

• Status code
• Headers
• Response body

For example:

HTTP/1.1 200 OK
Content-Type: text/html

The response body may contain the HTML for the webpage.

The status code tells the browser the general result of the request.

Some common examples are:

200 → OK
301 → Moved Permanently
302 → Found
400 → Bad Request
401 → Unauthorized
403 → Forbidden
404 → Not Found
500 → Internal Server Error

For example:

200 OK

generally means the request was successfully processed.

If the requested resource doesn't exist, the server might return:

404 Not Found

So the browser now has a response.

But it still has more work to do.

8. The Browser Receives HTML, CSS and JavaScript

The response may contain HTML.

For example:

<!DOCTYPE html>
<html>
<head>
    <title>My Website</title>
</head>
<body>
    <h1>Hello World</h1>
    <p>Welcome to my website.</p>
</body>
</html>

HTML gives the webpage its structure.

HTML → Structure

The HTML may also reference other resources such as CSS, JavaScript, images, and fonts.

For example:

<link rel="stylesheet" href="/style.css">

<script src="/app.js"></script>

<img src="/logo.png">

The browser can then make additional requests to retrieve those resources.

CSS

CSS (Cascading Style Sheets) controls how the webpage looks.

h1 {
    color: blue;
    font-size: 32px;
}

So:

CSS → Appearance

JavaScript

JavaScript adds behavior and interactivity.

For example:

button.addEventListener("click", () => {
    alert("Hello!");
});

So:

JavaScript → Behavior

A simple mental model is:

HTML       → Structure
CSS        → Appearance
JavaScript → Behavior

9. The Browser Builds the Page

Now the browser has to turn all these resources into something you can actually see.

The browser parses the HTML and builds the DOM (Document Object Model).

The DOM represents the webpage as a tree of elements.

For example:

<html>
    <body>
        <h1>Hello</h1>
        <p>Welcome</p>
    </body>
</html>

can be represented conceptually as:

html
└── body
    ├── h1
    │   └── "Hello"
    └── p
        └── "Welcome"

The browser also processes CSS to determine how those elements should look.

It then performs rendering work such as calculating layout and painting the page.

Very roughly:

HTML
 ↓
DOM

CSS
 ↓
Style Information

DOM + CSS
 ↓
Layout
 ↓
Paint
 ↓
Screen

JavaScript may also modify the page or request additional data while the page is loading or after it has loaded.

Finally:

You see the webpage.

So What Actually Happened?

Let's go back to the beginning.

You typed:

https://example.com

and pressed Enter.

Behind the scenes, a simplified version of the journey was:

1. Browser receives the URL
          ↓
2. Browser needs to find the destination
          ↓
3. DNS helps resolve the domain to an IP address
          ↓
4. Browser establishes the required connection
          ↓
5. HTTPS provides secure communication when applicable
          ↓
6. Browser sends an HTTP request
          ↓
7. Server receives and processes the request
          ↓
8. Server sends an HTTP response
          ↓
9. Browser receives HTML and other resources
          ↓
10. Browser processes HTML, CSS and JavaScript
          ↓
11. Browser renders the page
          ↓
12. You see the website

What looked like:

Type URL → Press Enter → Website

was actually closer to:

URL
 ↓
Browser
 ↓
DNS
 ↓
IP Address
 ↓
Connection
 ↓
HTTP Request
 ↓
Server
 ↓
HTTP Response
 ↓
HTML / CSS / JS
 ↓
Browser Rendering
 ↓
Web Page

One More Thing: Real Websites Can Be More Complicated

The flow above is a simplified mental model.

Real-world websites can involve many additional components, such as:

• Browser caching
• DNS caching
• HTTP caching
• CDNs
• Load balancers
• Proxies
• APIs
• Databases
• Cookies
• Sessions
• Redirects
• HTTP/2
• HTTP/3
• QUIC

For example, a real request might look more like:

Browser
   ↓
DNS
   ↓
CDN / Load Balancer
   ↓
Web Server
   ↓
Application Server
   ↓
Database
   ↓
Response
   ↓
Browser

But you don't need to understand everything at once.

The important thing is to understand the basic journey first.

Final Takeaway

The next time you type a URL and press Enter, remember that the webpage doesn't simply appear from nowhere.

The browser has to find the destination, communicate with the server, request the resource, receive the response, download additional resources, and finally render everything on your screen.

The whole process can be remembered as:

URL
 ↓
DNS
 ↓
IP Address
 ↓
Connection
 ↓
HTTP/HTTPS
 ↓
Request
 ↓
Server
 ↓
Response
 ↓
HTML / CSS / JS
 ↓
Browser Rendering
 ↓
Web Page

A simple action like pressing Enter hides a lot of interesting engineering underneath.

And that's what happens when you type a URL in the browser.

Thanks for reading!

If you're learning web development too, the next time you open a website, don't just look at the page.

Think about the journey that happened before you could see it.