# How the web works: DNS, hosting, HTTP and browsers in plain English

Source: https://sarang.pro/how-the-web-works-dns-hosting-http/
Author: Sarang | Published: 25 October 2026

Most founders use the web all day without needing to know how a page reaches the screen. That changes the first time a site goes down, a domain transfer stalls, or a developer says "it's a DNS issue, give it a few hours". At that point you are making decisions about suppliers and risk with words you only half understand.

This guide walks through what happens between typing an address and seeing a page, in the order it happens. It covers four parts: DNS, hosting, HTTP and the browser. Each one is a place where things can break, and each one has a different person or company responsible for it.

## The short version
MDN, Mozilla's developer documentation, explains the web with a shopping analogy in its guide to [how the web works](https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works). Your device is the house, the server is the shop, the internet connection is the street, DNS is the address book, and HTTP is the language you use to place an order. TCP/IP is the vehicle that carries goods along the street.

When you type example.com and press Enter, roughly four things happen:

- Your browser looks up the server's numeric address using DNS.
- It sends an HTTP request to that address, asking for the page.
- The server, which is the computer your hosting company runs, sends back a response with the files.
- Your browser reads the HTML, CSS and JavaScript and draws the page.
The rest of this article takes each step in turn.

## DNS: the address book
Computers find each other by IP address, a string of numbers. People prefer names. The Domain Name System translates one into the other. MDN calls it "like an address book for websites".

Cloudflare's explainer on [what DNS is](https://www.cloudflare.com/learning/dns/what-is-dns/) sets out the lookup in stages. Your request goes to a recursive resolver, usually run by your internet provider or a public service. If the resolver doesn't already know the answer, it asks a root nameserver, which points it to the server for the domain's ending, such as .com or .uk. That top-level domain server then points to the domain's authoritative nameserver, which Cloudflare describes as "the final source of truth" for the domain's records. The resolver passes the IP address back to your browser.

Most lookups are much faster than this because answers are cached in the browser, the operating system and the resolver. Each cached record is kept for a period set by its time to live (TTL). This is why DNS changes don't show up everywhere at once: some people still have the old answer stored until its TTL runs out.

Three things worth knowing as a business owner:

- **The registrar and the DNS host can be different companies.** You buy the domain from a registrar. The nameservers that hold its records may be at the registrar, at your hosting company or at a service like Cloudflare.
- **Records do different jobs.** An A record points a name to an IP address. An MX record says where email goes. Changing one carelessly can take your email down while the website keeps working.
- **Lower the TTL before a planned move.** If you are switching hosts, ask your developer to shorten the TTL a day or two in advance so the change spreads faster on the day.

## Hosting: where the files live
A website is a set of files: HTML documents, images, stylesheets, scripts and fonts. Those files have to sit on a computer that is always switched on and connected. MDN's page on [what a web server is](https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Web_mechanics/What_is_a_web_server) explains that "web server" can mean the hardware, the software or both. The software part is at minimum an HTTP server, which understands web addresses and the HTTP protocol, finds the requested file and sends it back. If the file isn't there, it returns a 404.

MDN separates two kinds of setup:

- **Static:** the server sends files exactly as stored. A brochure site or a portfolio often works this way, and it is cheaper and simpler to run.
- **Dynamic:** extra software, usually an application server and a database, builds each page before sending it. Shops, dashboards and anything with logins work this way.
When you pay for hosting you are paying someone to keep that computer available, connected and maintained. The questions to ask a host are practical. Who applies security updates? Where are backups kept and how quickly can they be restored? What happens to the site if traffic jumps?

## HTTP: the conversation
Once the browser has an address, it talks to the server using HTTP. MDN's [overview of HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview) describes it as "the foundation of any data exchange on the Web". The browser sends a request, and the server sends a response.

A request includes a method, such as GET to fetch something or POST to submit a form, plus the path of the resource and some headers. A response includes a status code, headers and usually a body containing the file.

Status codes are grouped by their first digit, and knowing the groups helps you read error reports:

Code rangeMeaningExample2xxSuccess200 OK3xxRedirect301 Moved Permanently4xxProblem with the request404 Not Found, 403 Forbidden5xxProblem on the server500 Internal Server Error, 503 Service UnavailableHTTP is stateless: each request stands alone. MDN notes that cookies are what make sessions possible, which is how a site remembers that you are logged in or what is in your basket. HTTPS is HTTP sent over an encrypted TLS connection, so the padlock in the address bar means the conversation between browser and server can't be read or altered in transit.

MDN also explains that data travels in small packets, each with a header saying where it is going and where it fits. If one packet is lost, only that piece needs resending.

## The browser: putting the page together
The browser reassembles the packets and reads the HTML first. The HTML refers to other files (stylesheets, scripts, images, fonts), so the browser makes further requests for each of those. It then works out the layout and paints the page. A single page view can involve dozens of requests, which is why heavy images and large scripts slow things down even on a fast connection.

## A worked example: the site that "went down"
An example (illustration only). A small online shop moves its website to a new host on a Friday afternoon. By evening, some customers see the new site, some see the old one, and the owner's email has stopped arriving.

Walking through the layers explains each symptom:

- **Mixed old and new site:** the DNS A record was changed, but resolvers that had cached the old IP address keep using it until the TTL expires. The record had a 24-hour TTL, so the switch takes up to a day to reach everyone.
- **Email stopped:** the developer moved the nameservers to the new host but didn't copy the MX records across. The website moved; the email instructions were lost.
- **Some pages show 404:** a few old addresses didn't exist on the new site and no 301 redirects were set up.
The fix list writes itself: copy every DNS record before moving nameservers, lower the TTL in advance, and map old addresses to new ones with redirects.

## Common mistakes and when this knowledge matters
- **Letting a developer own the domain.** Register the domain in a company account that you control, and give others access as users.
- **Treating DNS changes as instant.** Plan moves for quiet periods and allow for caching.
- **Ignoring 5xx errors.** A 4xx often means a broken link. A run of 5xx errors means the server or application is failing and needs attention now.
- **Skipping HTTPS on small sites.** Browsers flag pages without it, and forms sent over plain HTTP can be read in transit.
You don't need this detail to publish a blog on a hosted platform that handles everything. You do need it when you are choosing a host, moving a domain, diagnosing an outage or deciding who to call. Knowing which layer has failed tells you whether the problem sits with your registrar, your DNS provider, your host or your own code.