How Websites Actually Work — Domain, DNS, Hosting, Browser, Frontend & Backend
One request, traced end to end: what a domain actually points at, how the browser resolves it, where the server and database sit, and why the same code behaves differently once it's in production.
Type a web address into a browser and, within a fraction of a second, a page appears. Almost nobody stops to ask what actually happened in that gap — which is fine, until something breaks. Then the gap matters a great deal. This guide walks through it once, properly.
What a domain actually is
A domain name like infomogli.com is not an address. It's a label a human can remember, which points — indirectly, through a system called DNS — to the actual address of a server: an IP address such as 104.21.14.2. Buying a domain buys you the right to that label; it does not buy you server space, and it does not by itself make a website exist.
Registering a domain and setting up hosting are two separate purchases, from two possibly unrelated companies. New site owners frequently assume the domain registrar hosts the site — it usually doesn't.
DNS: turning a name into an address
DNS — the Domain Name System — is the directory that translates a domain name into the IP address of the server that should answer for it. When a browser needs infomogli.com, it asks a DNS resolver, which checks a chain of DNS servers until one returns an answer. The most common record types:
| Record | Purpose | Example |
|---|---|---|
A | Points a domain directly at an IPv4 address | 104.21.14.2 |
CNAME | Points a subdomain at another domain name | www → infomogli.com |
MX | Routes email for the domain | mail.infomogli.com |
TXT | Arbitrary text — often used for verification | v=spf1 … |
DNS answers are cached at several layers — the browser, the operating system, the internet provider — which is why a DNS change can take anywhere from a few minutes to 48 hours to be visible everywhere. That delay is usually called propagation.
Set a DNS record's TTL (time to live) lower a day before you plan to change it, then raise it again afterward. Shorter caching windows mean faster, more predictable propagation when the change actually happens.
Hosting and the server
Once DNS resolves a domain to an IP address, that address has to belong to something — a physical or virtual machine running a web server. This is what "hosting" means: renting time and space on a computer that stays switched on and connected to the internet, listening for requests.
- Shared hosting — many sites share one server's resources. Cheap, limited, fine for small low-traffic sites.
- VPS (virtual private server) — a slice of a server reserved for you, with root access. More control, more responsibility.
- Managed platforms (Vercel, Laravel Forge, etc.) — someone else handles the server; you handle the code.
The server doesn't know or care what a "website" is. It's a program listening on port 80 or 443, waiting for a specific kind of text message called an HTTP request.
The request and response
When the browser has an IP address, it opens a connection to the server and sends an HTTP request — a plain-text message describing what it wants. The server reads it, does whatever work is needed, and sends back an HTTP response.
GET / HTTP/1.1
Host: infomogli.com
User-Agent: Mozilla/5.0
Accept: text/htmlHTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4821
<!doctype html>
<html>…</html>200 means success. A 404 means the server couldn't find what was asked for; a 500 means the server hit an error while trying to answer. Every status code you've ever seen in a browser tab is one of these three-digit numbers, defined by a decades-old standard almost nobody reads anymore.
Frontend: what the browser renders
The response body above is HTML — the structure of the page. The browser parses it, fetches any linked CSS and JavaScript, and assembles what you actually see. This is "the frontend": everything that runs inside the browser, on the visitor's own machine, using their own device's processing power.
Frameworks like React don't change this fundamental exchange — they change how the HTML gets built. A traditional site sends finished HTML from the server; a React single-page app often sends a mostly empty HTML shell and a large JavaScript file that builds the page client-side, after the fact. Both still start with the same request and response above.
Backend: where the logic lives
"Backend" is everything that happens on the server before it sends a response — reading from a database, checking who's logged in, calculating a total, deciding what content to send back. A Laravel application, for instance, receives the incoming request, runs it through routing and a controller, and returns HTML or JSON:
Route::get('/', function () {
return view('home', [
'guides' => Guide::latest()->take(3)->get(),
]);
});Anything sent to the browser — HTML, JavaScript, even API responses — can be read and modified by the visitor. Never trust data or logic that only exists on the frontend for anything security-related; the backend has to check it too.
Putting it together
A single page load, in order: the browser resolves the domain through DNS, opens a connection to the resulting IP address, sends an HTTP request, the server's backend code runs — often querying a database — and returns a response, which the browser's frontend machinery turns into what you see on screen. Hosting is simply where the server lives. Deployment is the process of getting your code onto that server in the first place.
"It works on my machine" almost always means a difference somewhere in this chain — a missing environment variable, a different PHP version, a database that exists locally but not on the server. Debugging deployment issues means checking each link, not guessing at the code.
None of this is complicated once it's laid out in order. It's only confusing when the six pieces get treated as one mysterious thing called "the internet."
Last updated Aug 22, 2026 — corrected the DNS propagation section.
Launching a website? Use the Website Launch Checker →