How Does X Work? X can be anything.

Editorial Standards · How We Research

How Does a Web Browser Work?

•

•

17–26 phút

Editorial disclosure: We may earn a commission from qualifying purchases made through links in this article. Our editorial opinions remain independent.

A web browser works by requesting information from web servers, interpreting the code it receives, and turning that information into interactive pages on your screen. When you enter a website address, the browser locates the server, establishes a connection, downloads resources such as HTML, CSS, and JavaScript, and processes them to display the page.

Behind this apparently simple process, several systems work together. A networking component handles communication, a rendering engine determines how the page should look, and a JavaScript engine runs code that makes the website interactive.

The browser also manages cached files, cookies, security permissions, and other information needed to make websites function efficiently and safely.

What Is a Web Browser?

A web browser is a software application that retrieves, interprets, and displays content from the World Wide Web.

Popular examples include Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge.

Although these browsers look different, they perform many of the same fundamental tasks.

They allow users to:

  • Enter website addresses and navigate between pages.
  • Communicate with web servers using protocols such as HTTP and HTTPS.
  • Interpret HTML, CSS, and JavaScript.
  • Display text, images, video, and other web content.
  • Interact with forms, buttons, menus, and web applications.
  • Store certain website information and enforce security restrictions.

According to MDN’s explanation of how browsers load websites, browsers transform downloaded web resources into structured information that can be rendered as a visible page.

A browser is not the internet itself. It is an application that uses internet connectivity to access web resources.

The distinction matters because the same internet connection can support email applications, online games, video calls, and other services without requiring a conventional web browser.

What Are the Main Components of a Web Browser?

A modern browser contains several cooperating software components.

ComponentMain Function
User interfaceProvides the address bar, tabs, navigation controls, and menus
Networking systemManages requests, responses, and network connections
Rendering engineProcesses page structure and styles to produce visual output
JavaScript engineExecutes JavaScript programs
Storage systemManages cookies, cached responses, and website data
Security architectureRestricts how websites access data and device capabilities

These are functional categories rather than a universal set of separate processes. Actual implementations vary among browsers.

Rendering Engine vs. JavaScript Engine

The rendering engine and JavaScript engine perform different jobs.

The rendering engine processes the structure, styling, and visual layout of a page.

The JavaScript engine executes program instructions that can change the page or respond to user actions.

For example, when you click a button that opens a menu, JavaScript might update the document. The rendering system then processes the necessary visual changes.

Some browser technologies use different engines.

Chromium-based browsers use Blink for rendering and V8 for JavaScript execution. Firefox uses Gecko and SpiderMonkey, while Safari uses WebKit and JavaScriptCore.

Despite implementation differences, these systems support broadly similar web standards.

How Does a Web Browser Work Step by Step?

Consider what happens when you enter:

https://www.example.com

The process can be divided into several major stages.

These stages may overlap, and browsers can reuse previously established connections or cached information rather than repeating every operation.

Step 1: The Browser Interprets the URL

When you type an address into the browser’s address bar, the browser first determines what action to perform.

If you enter a valid URL, it can navigate to the specified resource.

If you enter ordinary words, the browser may instead send them to its configured search engine.

For example:

https://www.example.com/products

The browser can identify several components:

  • Scheme: https, indicating the communication scheme.
  • Hostname: www.example.com, identifying the requested host.
  • Path: /products, identifying the requested resource.

A URL can also contain a port number, query parameters, and a fragment identifier.

The browser uses this information to determine where to send the request and what resource to request.

Step 2: The Browser Finds the Server’s IP Address

A browser usually needs network address information before it can communicate with a remote web service.

The hostname is human-readable, but internet packet delivery relies on IP addressing.

The Domain Name System (DNS) helps resolve domain names into the information required to contact the destination.

The browser or operating system may first check for a usable cached result.

If no appropriate result is available, a DNS query can be sent to a configured resolver.

That resolver obtains the relevant DNS records, either from its own cache or through additional queries.

For example, an A record provides an IPv4 address, while an AAAA record provides an IPv6 address.

The browser can then attempt to connect using a suitable address.

As explained in MDN’s browser-loading guide, DNS resolution is part of the navigation process when the browser needs to locate a server.

A browser does not need a fresh DNS lookup every time you open a page. Cached records and existing connections can eliminate some of this work.

Step 3: The Browser Establishes a Connection

Once the browser has suitable destination information, it needs to communicate with the server.

The exact process depends on the web protocol and transport being used.

For HTTP/1.1 or HTTP/2 over HTTPS, the browser typically uses TCP and TLS.

TCP establishes reliable, ordered communication between endpoints.

TLS authenticates the server and protects the connection through encryption and integrity checks.

Modern browsers can also use HTTP/3, which runs over QUIC instead of TCP.

QUIC combines secure transport with capabilities such as reliable streams and connection management.

The browser may reuse an existing connection when the protocol and security conditions permit.

This can reduce the overhead of establishing new connections.

For secure websites, HTTPS helps protect information exchanged between the browser and the secure endpoint.

However, establishing a secure connection does not mean the website itself is automatically trustworthy.

Step 4: The Browser Sends an HTTP Request

After establishing the necessary communication, the browser requests the desired resource.

This exchange uses the Hypertext Transfer Protocol, or HTTP.

For example, a simplified HTTP/1.1 request might look like this:

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

This example asks the server for the /products resource and indicates that the client can accept HTML content.

An actual browser request may include additional headers describing supported content formats, caching conditions, language preferences, cookies, and other relevant information.

The server then processes the request and prepares a response.

As explained in the MDN HTTP overview, browsers act as HTTP clients, while servers provide responses containing requested resources or information about the request’s outcome.

This request-and-response mechanism is fundamental to how web browsing works.

Step 5: The Web Server Sends a Response

The web server receives the request and determines how to handle it.

It might retrieve an existing HTML document, run application code, consult a database, or forward the request to another service.

The server then returns an HTTP response.

A simplified example is:

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

The response body would contain the HTML document.

The 200 OK status means the request succeeded.

Other responses indicate different outcomes.

HTTP StatusMeaning
200The request succeeded
301The resource has permanently moved
304A cached resource can be reused under the applicable validation rules
403Access to the resource is forbidden
404The requested resource was not found
500The server encountered an internal error

The browser interprets the response and determines what to do next.

For example, it may follow a redirect, display a page, reuse cached content, or report an error.

Not every response produces a new visible document.

Some responses provide data for an existing application, download a file, or update part of the current page.

Step 6: The Browser Reads the HTML

When the browser receives HTML, its rendering system begins parsing the document.

Parsing converts the markup into an internal representation called the Document Object Model, or DOM.

The DOM represents the elements and relationships within a page.

Consider this simple HTML:

<h1>Hello, World!</h1>
<p>Welcome to my website.</p>

The browser interprets these elements as part of a structured document.

The h1 element represents a heading, while the p element represents a paragraph.

The DOM organizes these elements into a tree-like structure.

This structure is important because the browser uses it to understand the page and because JavaScript can inspect or modify it.

The browser can begin processing HTML before the entire response has finished downloading.

While parsing, it may discover additional resources that need to be retrieved, including stylesheets, images, fonts, and scripts.

Those resources can trigger more network requests.

Step 7: The Browser Processes CSS

HTML describes the structure of a webpage, but it does not fully define its visual appearance.

Cascading Style Sheets (CSS) provide styling information.

CSS can control:

  • Text color and typography.
  • Background colors and images.
  • Element dimensions and spacing.
  • Positioning and layout.
  • Responsive behavior across screen sizes.
  • Animations and visual effects.

For example:

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

This rule tells the browser to display matching headings in blue at the specified font size.

The browser parses CSS and builds an internal representation of the applicable styling rules, commonly described as the CSS Object Model (CSSOM).

It combines document structure with style information to determine which elements should be displayed and how they should appear.

Some content can affect document structure without appearing directly on screen.

For example, metadata inside the HTML head is generally not part of the visible page.

According to MDN’s critical rendering path documentation, browsers use information from the DOM and CSSOM to determine the visual structure needed for layout and painting.

Step 8: The Browser Executes JavaScript

JavaScript allows web pages to perform actions beyond displaying static content.

A JavaScript program might:

  • Respond when someone clicks a button.
  • Validate information entered into a form.
  • Request new data without navigating to another page.
  • Open or close menus.
  • Update visible content.
  • Control interactive graphics.

For example:

document.querySelector("h1").textContent = "Hello, Browser!";

This code finds the first matching heading element and changes its text.

The JavaScript engine executes the instruction, and the browser updates the corresponding document state.

If the change affects what appears on screen, the rendering system performs the necessary visual updates.

JavaScript execution does not always happen after all HTML and CSS processing is complete.

Scripts can run during page loading, and certain scripts may delay HTML parsing or rendering.

Modern browsers also support mechanisms that allow different work to proceed asynchronously.

The JavaScript event loop helps coordinate tasks, user interactions, and callbacks without requiring every operation to block the entire page.

The MDN JavaScript execution model describes how execution contexts, job queues, and the event loop support this behavior.

Step 9: The Browser Calculates the Page Layout

Once the browser has enough document and styling information, it determines where elements belong on the screen.

This stage is called layout.

The browser calculates properties such as:

  • Element width and height.
  • Position relative to other elements.
  • Text wrapping.
  • Margins and padding.
  • Available space within containers.

For example, a webpage containing two columns might display them side by side on a desktop monitor.

On a narrow smartphone screen, responsive CSS may cause those columns to appear vertically instead.

The browser must calculate the appropriate geometry for the current viewing environment.

Layout is not necessarily performed only once.

Changes to text, element dimensions, window size, or certain CSS properties can require additional layout calculations.

This recalculation is sometimes called reflow.

Step 10: The Browser Paints the Page

After determining the layout, the browser can produce the visual output.

The painting stage involves generating the drawing operations needed to represent visible elements.

These can include text, backgrounds, borders, images, and shadows.

Modern browsers may divide parts of the page into layers.

Some layers can be rasterized or composited using graphics hardware, depending on the browser, platform, and content.

Compositing combines the relevant visual layers into the final image displayed on the screen.

This process helps browsers update certain visual elements efficiently.

For example, an animated element may be handled through compositing without recalculating the layout of the entire page on every frame, if the necessary conditions are met.

The exact rendering pipeline varies by browser implementation.

The essential sequence remains:

Document structure → Styles → Layout → Paint → Compositing → Display

At this point, the browser has turned downloaded code and resources into a visible webpage.

However, the work is not necessarily finished.

JavaScript may continue running, images may arrive later, and user interactions can trigger new rendering updates.

How Do HTML, CSS, and JavaScript Work Together?

A browser uses HTML, CSS, and JavaScript for different but related purposes.

TechnologyMain ResponsibilityExample
HTMLDefines structure and contentA heading, paragraph, image, or form
CSSDefines visual styling and layoutColors, fonts, spacing, and responsive columns
JavaScriptDefines interactive behaviorOpening a menu or updating content

Consider a shopping website.

HTML defines the product name, price, and Add to Cart button.

CSS determines how those elements look on desktop and mobile screens.

JavaScript may respond when the customer presses Add to Cart, update the cart counter, and communicate with the website’s backend.

The browser coordinates all three.

A website can also use server-side systems to generate or retrieve content, but those systems are separate from the browser’s client-side work.

How Does a Browser Respond When You Click Something?

Loading a page is only the beginning of browser activity.

Once the page is interactive, the browser must respond to user input.

Suppose you click a button labeled “Show Details.”

The browser receives the input event and delivers it to the appropriate part of the webpage.

If the website has registered a JavaScript event handler for that button, the browser can execute the corresponding code.

The code might change the DOM to reveal a hidden paragraph.

If the change affects the visual appearance of the page, the browser updates the necessary rendering information.

This can involve recalculating styles, performing layout, painting, or compositing, depending on what changed.

Not every interaction requires all these steps.

For example, some visual changes can be handled more efficiently than changes that alter element dimensions or document structure.

Similarly, clicking a link may trigger navigation to an entirely different document.

The browser then begins another navigation and loading process.

How Does Browser Caching Work?

Browsers often store previously retrieved resources so they do not need to download the same information repeatedly.

This is called browser caching.

For example, a website might use the same logo, stylesheet, and JavaScript file across several pages.

If the browser has an appropriately cached copy, it may reuse that resource rather than downloading it again.

Caching can reduce network traffic and improve loading performance.

However, cached content is not always reused indefinitely.

Servers can provide HTTP caching instructions indicating how resources should be stored and when they need to be checked for updates.

What Happens When Cached Content Expires?

A cached resource can become stale.

Depending on its cache settings, the browser may contact the server to determine whether the resource has changed.

For example, it may send a conditional request using a previously received ETag.

If the server determines that the resource has not changed, it may return:

304 Not Modified

The browser can then reuse its cached copy according to the applicable rules.

If the resource has changed, the server can return updated content.

MDN’s HTTP caching guide explains how freshness, validation, and cache directives affect this process.

Can a Browser Work Offline?

Sometimes.

A browser can display certain previously stored resources without an active internet connection.

Some web applications also use service workers to intercept requests and provide cached responses.

This can allow selected functionality to continue offline.

For example, a properly designed web application might display previously downloaded content even when connectivity is unavailable.

However, ordinary websites do not automatically become fully functional offline.

Features requiring live server communication, authentication, or updated remote information may stop working.

The Service Worker API documentation explains how applications can implement offline resource handling.

How Do Cookies Work in a Web Browser?

Cookies are small pieces of data that websites can ask browsers to store and send with applicable future requests.

They help support features such as login sessions, shopping carts, and saved preferences.

For example, after you sign in to a website, the server may issue a session cookie.

The browser stores that cookie according to its attributes and policies.

During later requests to the same service, the browser may include the cookie so the server can recognize the ongoing session.

Cookies do not necessarily contain your password.

Often, they contain a session identifier or another value that the server uses to retrieve associated information.

Cookies vs. Cache vs. Local Storage

These browser storage mechanisms have different roles.

Storage TypeMain Purpose
CookiesMaintain small pieces of state, often associated with HTTP requests
HTTP cacheStore reusable responses and resources
Local storageStore website-associated data accessible through supported browser APIs
IndexedDBStore more structured application data locally

Browsers apply rules that restrict which websites can access stored information.

For example, the same-origin policy limits a website’s ability to access data belonging to another origin.

Modern browsers also implement various forms of storage partitioning to help reduce unwanted tracking across websites.

MDN’s state partitioning guide describes how browsers can separate storage according to the top-level website context.

These protections vary by browser, version, and settings.

How Does a Web Browser Keep You Secure?

Web browsers must process content supplied by websites that may not be trustworthy.

This creates a security challenge.

A browser needs to run interactive web applications while limiting their ability to access unrelated data or sensitive operating-system resources.

Modern browsers address this problem through several layers of protection.

HTTPS and Certificate Verification

When you connect to an HTTPS website, the browser uses TLS to establish protected communication with the appropriate endpoint.

During connection establishment, the browser verifies the server’s certificate according to its trust and hostname validation rules.

If certificate verification fails, the browser may display a security warning.

However, a valid certificate does not guarantee that a website is honest, harmless, or free of malware.

It helps authenticate the endpoint and establish a protected connection.

The Same-Origin Policy

Browsers apply a security principle called the same-origin policy.

An origin is generally defined by a URL’s scheme, hostname, and port.

For example:

https://store.example.com

and

https://mail.example.com

have different origins because their hostnames differ.

The same-origin policy restricts how scripts from one origin can read or manipulate resources associated with another origin.

Without this protection, a malicious website might attempt to read sensitive information from another website where you are logged in.

The MDN same-origin policy documentation explains these restrictions and the circumstances under which cross-origin interactions are permitted.

The policy is not a rule that prevents all communication between websites.

Browsers support controlled cross-origin requests, embedded resources, and mechanisms such as Cross-Origin Resource Sharing (CORS), subject to the relevant security rules.

Browser Sandboxing

Many browsers also isolate untrusted webpage code within restricted execution environments.

This approach is called sandboxing.

A sandbox limits the capabilities available to code running inside it.

For example, webpage code should not automatically gain unrestricted access to your computer’s files or operating-system functions.

Chromium-based browsers use a multi-process architecture and sandbox restrictions to help contain untrusted content.

Chrome also implements site isolation, which provides additional separation between websites.

As described in Chromium’s Site Isolation documentation, these measures help reduce the impact of certain vulnerabilities by keeping sensitive website data separated across security boundaries.

Sandboxing does not guarantee that security vulnerabilities can never be exploited.

It is one layer of defense within a broader browser security architecture.

What Happens in Incognito or Private Browsing Mode?

Private browsing changes how certain browsing data is stored and retained locally.

For example, a private browsing session generally avoids keeping ordinary browsing history after the private session closes.

Cookies and temporary website data associated with that session are also typically discarded when the relevant private browsing session ends, subject to browser-specific behavior.

However, private browsing does not make someone invisible on the internet.

The websites you visit can still receive network information associated with your connection.

Your internet service provider or network administrator may still observe connection metadata.

Downloads, bookmarks, or other explicitly saved information may remain on your device.

Private browsing is therefore primarily a local privacy feature, not a complete anonymity system.

Why Do Some Websites Load Slowly in a Browser?

Website loading speed depends on several different systems.

The browser must obtain resources over the network, process those resources, execute relevant code, calculate layout, and produce visual output.

A delay can occur at any of these stages.

Network Delays

A slow connection can increase the time required to retrieve webpage resources.

DNS lookups, connection establishment, network latency, server processing, and download throughput all affect the loading process.

A website using a content delivery network (CDN) may deliver suitable cached resources from infrastructure closer to the user.

However, a CDN cannot eliminate every type of network or application delay.

JavaScript Processing

Large or computationally expensive JavaScript tasks can delay user interactions.

For example, if the browser’s main thread is occupied with a long-running task, it may not immediately process clicks or update the display.

This can make a page feel unresponsive even when the internet connection is fast.

Layout and Rendering Work

Complex layouts, numerous document elements, large images, and frequent changes to page geometry can increase rendering work.

Some changes require the browser to recalculate layout or repaint parts of the page.

As described in MDN’s browser performance guide, networking and rendering both influence how quickly a page becomes usable.

A browser must coordinate these activities rather than simply wait for a complete file to arrive.

What Is the Difference Between a Browser, Search Engine, and the Internet?

These terms describe different technologies.

TechnologyWhat It DoesExamples
Web browserRetrieves and displays web resourcesChrome, Firefox, Safari, Edge
Search engineSearches an index or collection of information to return resultsGoogle Search, Bing, DuckDuckGo
InternetConnects computer networks globallyThe underlying network infrastructure

A search engine can be accessed through a browser, but it is not the same software.

For example, Google Chrome is a web browser.

Google Search is a search service.

You can use Chrome to visit a website directly without searching for it.

Likewise, you can use different search engines within the same browser.

The internet provides the connectivity that allows these systems to communicate.

Does a Browser Download an Entire Website?

Usually not.

When you visit a webpage, the browser generally requests the resources needed for that page and its current functionality.

It does not automatically download every page, database, or file belonging to the entire website.

Some resources may be loaded immediately.

Others may be requested later when you scroll, click a button, navigate to another page, or interact with an application.

For example, a website might delay downloading images that are far below the visible portion of the page.

This technique is called lazy loading.

Modern web applications can also request new information in the background and update selected parts of the page without navigating to a completely new document.

As a result, browsing is often an ongoing exchange between the application, browser, and remote services—not a single download followed by a static display.

What Happens When You Close a Browser Tab?

Closing a tab generally ends its active browsing context.

Depending on the browser’s architecture, the associated rendering processes and other resources may be released, reused, or retained temporarily.

The browser may also preserve some navigation or session information to support features such as reopening recently closed tabs.

Closing a tab does not necessarily erase cookies, browser history, or stored website data.

Those are managed separately according to browser settings and storage rules.

This explains why a website may remember that you are logged in even after you close its tab and open it again.

The browsing session, stored authentication information, and active tab are related but distinct concepts.

A Browser Turns Web Code Into an Interactive Experience

A web browser works by coordinating network communication, document processing, program execution, and visual rendering.

It interprets a URL, obtains the necessary address information, establishes communication, requests resources, and processes the server’s response.

HTML provides the document structure. CSS supplies styling rules. JavaScript enables interactive behavior. The rendering engine calculates layout and produces the pixels displayed on your screen.

Meanwhile, caching, storage, and security systems help the browser manage resources and protect information.

The central idea is simple: a website sends information, but the browser is responsible for interpreting that information and transforming it into the page you see and use.