How Browsers Work

Why it matters

"The site is broken" can mean a DNS record pointing at the wrong server, an expired certificate, a 500 response, a stylesheet that returned 404 or a JavaScript error that stopped a click handler. Each has a different owner and a different fix. A tester who knows the steps can say which one it is and attach the evidence, instead of filing a report nobody can act on.

The steps also show what to test. A page is dozens of requests and several stages of processing, and each can fail on its own: on a slow network, in another browser, or with an outdated cached file.

Fetching the page: from URL to response

The browser splits the address into scheme (https), host (shop.example.com), path, query and fragment; the fragment, such as #reviews, is never sent to the server. If the browser cache holds a fresh copy of the response, the browser may skip the network entirely. Otherwise the network steps run in order:

• DNS lookup: the host name becomes an IP address, such as 203.0.113.10. Answers are cached, so a DNS change may not show at once. If the name does not resolve, the browser shows its own error page (in Chrome, DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED) and no request reaches the server.
• Connection: the browser opens a TCP connection, on port 443 for HTTPS, and keeps it open for later requests. HTTP/3 uses QUIC over UDP instead, which sets up the connection and the TLS encryption in one combined handshake.
• TLS handshake: the browser and the server agree on encryption keys, and the browser checks that the server's certificate comes from a trusted authority, is in date and covers this host name. A failed check shows a full-page warning instead of the site, in Chrome with a code such as NET::ERR_CERT_DATE_INVALID.
• HTTP request: a method and a path, such as GET /products/42, with headers like Host and User-Agent and the cookies stored for the site.
• HTTP response: a status code such as 200, 404 or 500, headers like Content-Type (the kind of file, such as text/html) and Cache-Control, and a body. A redirect (301, 302) sends the browser back to the first step with the URL in its Location header.

Try it: URL Parser Try it: Redirect Checker

Building the page: HTML, CSS, JavaScript, render

The browser parses the HTML while it is still arriving: it decodes the bytes with the declared character set and builds the DOM, the tree of elements that scripts and test tools work with. The parser repairs broken markup silently, so bad HTML rarely shows an error. Every stylesheet, script, image and font the page refers to becomes another request, and any of them can fail while the page itself returns 200.

• CSS: stylesheets in the <head> block rendering. The browser waits for them before the first paint, and if one fails, the page appears without its styles.
• JavaScript: a plain <script src> pauses the parser until the script has run; defer waits until parsing ends, async runs on arrival. Scripts change the DOM, attach click handlers and request data. An uncaught error stops the code that was running, so a page can look complete while a button does nothing.
• Render: the browser computes each element's style, lays out every box and paints the pixels. Later changes, such as an image without reserved space or a banner a script inserts, trigger layout and paint again, which is why content can jump.
• Milestones: DOMContentLoaded fires when the HTML is parsed and deferred scripts have run; load fires when images, stylesheets and other resources have finished too.

What a tester can observe at each step

Browser developer tools (DevTools: F12 in Chrome, Edge and Firefox, or Cmd+Option+I on a Mac) show almost every step; a later lesson tours their panels. The Network panel lists one row per request with its status, type, size and timing, and its summary bar shows the DOMContentLoaded and load times. It records only while it is open, so open it first, then reload. It can export all rows as a HAR file (HTTP Archive), a JSON file that another person can open in their own DevTools.

• Before any request: DNS, connection and certificate failures show a code on the browser's own error page. No HTTP request was sent, so the server's access logs have no entry for it. The site-information icon at the left of the address bar opens the certificate, with its issuer and validity dates.
• The Timing view of one request: phases such as DNS lookup, connecting, TLS, waiting for the server and downloading. The names vary slightly between browsers.
• The Headers and Response tabs: what was sent (method, URL, headers, cookies) and what came back (status, headers, body). Chrome marks rows served from the cache as (disk cache) or (memory cache); the "Disable cache" checkbox makes reloads skip the browser cache while DevTools is open.
• Page source and Elements: View page source (Ctrl+U on Windows) shows the HTML exactly as it arrived; the Elements panel (Inspector in Firefox) shows the DOM after the parser's repairs and the scripts' changes.
• The Console: JavaScript errors and refused resources, with file and line. Rendering problems show only on the screen, so capture screenshots or a recording.

Try it: Request Header Inspector Try it: HTTP Headers Parser

Worked example: a product page without styles

After a release to staging, the test copy of the site where a release is checked before it reaches production, a tester opens https://staging.shop.example.com/products/42. Text and images appear, but in one plain column with default fonts. Walking the steps finds the cause in minutes:

• The page appeared, so DNS, the connection and TLS worked. The document row is 200 and the text is readable, so the HTML arrived and was decoded correctly.
• The row for app.3f9c1e.css is 404 with Content-Type: text/html: the server sent its "not found" page instead of the stylesheet, and the Console says the browser refused it because its MIME type, the file type named in Content-Type, is not text/css.
• So the HTML refers to a CSS file the server does not have: either the file was not deployed or the HTML names the wrong file. It is a build or deployment defect, not a defect in the CSS code, and it affects every browser. The bug report carries the evidence:

Title:    Product page unstyled on staging: app.3f9c1e.css returns 404
URL:      https://staging.shop.example.com/products/42
Build:    web 2.14.0 on staging
Request:  GET https://staging.shop.example.com/assets/app.3f9c1e.css
Response: 404 Not Found, Content-Type: text/html; charset=utf-8
Console:  Refused to apply style from '.../assets/app.3f9c1e.css' because its
          MIME type ('text/html') is not a supported stylesheet MIME type,
          and strict MIME checking is enabled.
Expected: 200 with Content-Type: text/css
Evidence: screenshot; HAR file of a reload with the cache disabled

Try it: Content-Type Validator Try it: HTTP Status Code Lookup

Frequently asked questions

References

• HTML Living StandardWHATWGThe HTML language, including named character references (entities) and the parsing rules browsers follow.
• Fetch StandardWHATWGDefines CORS: preflight requests, the Access-Control-* headers and which responses a browser may expose to a page.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018The TLS 1.3 handshake and record protocol that protect HTTPS traffic.