How the web works

A URL such as https://shop.example.com/shoes?colour=red#reviews has several parts: the scheme (https), the host name (shop.example.com), the path (/shoes), a query string of key-value pairs (?colour=red) and an optional fragment (#reviews) that points to a spot on the page. A port number can follow the host, but browsers hide the defaults, 443 for HTTPS and 80 for HTTP.

Characters with a special meaning, such as spaces, question marks and ampersands, must be percent-encoded, so a space becomes %20. The fragment never reaches the server; it stays in the browser. Clean, stable, readable URLs help people and search engines alike, and changing them later needs redirects so that old links keep working.

Computers find each other by IP address, a string of numbers; domain names exist so people do not have to remember them. A name reads from right to left: in shop.example.com, .com is the top-level domain, example is the part you register, and shop is a subdomain you can create yourself, free and as many as you like.

A domain is rented, not owned. You register it for one to ten years through a registrar and keep it as long as you renew. If it lapses, a grace period and then a costly redemption period follow, after which anyone can register it, and expired names that still get traffic are quickly snapped up for resale. Registering the name, running its DNS and hosting the site are three separate jobs, even when one company sells all three.

Each TLD is run by a registry: Verisign runs .com, for example, and NIXI runs .in. Generic TLDs (gTLDs) such as .com, .net and .org, and newer ones such as .app, .dev and .shop, are open to anyone. Country-code TLDs (ccTLDs) such as .in, .uk and .de belong to a country, and some come with residency or paperwork rules. A few country codes, such as .io and .ai, became popular with tech startups.

The registry sets the wholesale price, so prices vary widely: a .com costs about $11 a year at cost, a .ai around $80, and premium names hundreds or thousands. Some TLDs have quirks: browsers load .app and .dev sites only over HTTPS. Google treats most ccTLDs as a sign that a site targets that country, but handles popular ones such as .io and .ai as generic; for most businesses a .com or their local ccTLD is the safe choice.

Registries run each TLD, but you buy through a registrar, which records you as the holder, collects the yearly fee and lets you set the domain's nameservers and contact details. Most also sell DNS hosting, email, website builders and certificates on the side, and those add-ons are where many make their margin.

Prices differ more than they first seem. Retail registrars often sell the first year cheaply and charge much more on renewal: GoDaddy renews a .com at about $23 and Namecheap at about $18.50, while Cloudflare Registrar and Porkbun charge close to the registry's own price, about $11. Hiding your name and address from public WHOIS lookups is free at most registrars, though a few still sell it as an extra.

Moving a domain to another registrar is a transfer: unlock it, get an authorisation code (the EPP code) from the old registrar and pay the new one, which usually adds a year to the registration. Domains cannot move for a while after being registered or transferred. Turn on auto-renew and two-factor sign-in, because losing a domain takes the website and email with it.

When you open a site, your device asks a resolver (run by your internet provider, or a public one such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8) for the domain's address. The resolver works down the hierarchy: the root servers point to the servers for .com, which point to the domain's own nameservers, which hold the actual answer. Answers are cached along the way for as long as their TTL (time to live) allows, so repeat lookups come back in a few milliseconds.

Caching is also why DNS changes are not instant: old answers linger until their TTL runs out, so lowering the TTL a day before a planned move helps. DNSSEC signs answers so they cannot be forged, and DNS over HTTPS (DoH) encrypts lookups so the local network cannot see or tamper with them.

The common types: an A record points a name at an IPv4 address and AAAA at an IPv6 address; a CNAME makes one name an alias of another (www pointing at a host's address, for example); MX records name the servers that receive email; TXT records hold text, used to prove you own a domain and for email rules such as SPF, DKIM and DMARC. NS records name the nameservers, and CAA records say which certificate authorities may issue certificates for the domain.

Every record has a TTL that sets how long others may cache it. The bare domain (example.com, called the apex) cannot be a CNAME under the standard rules, so DNS hosts offer an ALIAS or ANAME record, or CNAME flattening, instead. When you connect a site to Vercel or Netlify, or an email service, the provider lists the exact records to add.

At the registrar, each domain lists its nameservers, usually two to four names such as ns1.example.net. The registry's servers send every lookup for the domain on to them, so they are the single source of truth for its records. By default they belong to the registrar, but you can point them elsewhere, for example to Cloudflare to use its free DNS, CDN and security features.

Changing nameservers moves all DNS management at once, so copy every existing record to the new provider first, especially the MX and TXT records for email, or mail will quietly stop arriving. The switch can take hours, occasionally a day or two, to reach everyone, because old answers stay cached.

Every exchange is a request and a response. The request names a method (GET, POST), a URL and headers (who is asking, which formats they accept, any cookies); the response carries a status code (200, 404), headers and a body, such as HTML, JSON or an image. HTTP itself is stateless: each request stands alone, and cookies or tokens are how a server recognises a returning visitor.

HTTPS wraps the same conversation in TLS encryption, backed by the site's certificate. Browsers label plain HTTP pages 'Not secure', and many features, such as service workers, geolocation and passkeys, work only over HTTPS. Newer versions change how the bytes travel, not what they mean: HTTP/2 sends many requests over one connection, and HTTP/3 runs over QUIC on UDP to cope better with slow or patchy mobile networks.

GET fetches data and should never change anything, which is why browsers, caches and search crawlers feel free to repeat it. POST sends data to create something or trigger an action, such as placing an order. PUT replaces a resource, PATCH updates part of it and DELETE removes it. HEAD asks for the headers only, and OPTIONS asks what is allowed, which browsers use for CORS preflight checks.

Some methods are idempotent, meaning that sending them twice has the same effect as sending them once: GET, PUT and DELETE are, POST is not. That matters when a network hiccup makes a client retry, and it is why payment APIs ask for an idempotency key on POST requests, so a retried payment is not charged twice. REST APIs map these verbs onto create, read, update and delete.

The first digit gives the family. 2xx means success (200 OK, 201 Created, 204 No Content). 3xx is a redirect (301 moved permanently, 302 or 307 moved for now, 304 not modified, so use the cached copy). 4xx is a problem with the request (400 bad request, 401 not signed in, 403 not allowed, 404 not found, 429 too many requests), and 5xx a problem on the server (500 internal error, 502 bad gateway, 503 unavailable, 504 gateway timeout).

The right code matters beyond tidiness. Search engines follow a 301 and pass rankings to the new URL, but treat a 'page not found' message sent with a 200 status as a 'soft 404'. Monitoring, retries and caches rely on these numbers too: a 503 with a Retry-After header tells clients to come back later, while a 400 tells them that retrying the same request will not help.

TLS (Transport Layer Security) is the encryption behind HTTPS; SSL is its retired predecessor, but the old name stuck. A certificate ties a domain name to a public key and is signed by a certificate authority (CA) that browsers trust. On each connection the browser checks the signature, the name and the expiry date, then agrees keys with the server so the rest of the conversation is private and tamper-proof.

Let's Encrypt, a non-profit CA, issues free domain-validated (DV) certificates automatically, and hosts such as Vercel, Netlify and Cloudflare set them up for you. Paid organisation-validated (OV) and extended-validation (EV) certificates also check the business behind the site, but browsers no longer display that difference prominently, and the encryption is the same.

Lifetimes are shrinking by industry rule: public certificates have been capped at 200 days since March 2026, falling to 100 days in 2027 and 47 days in 2029. Renewing by hand stops being practical, so automatic renewal through the ACME protocol, which Let's Encrypt pioneered, is effectively required.

An API is a contract: send a request in this shape and you get a response in that shape. On the web it usually means an HTTP API, where an app calls URLs (endpoints) such as /orders/42 and receives JSON. The provider documents what each endpoint does and issues keys or tokens, so it knows who is calling and can limit or bill them.

The term is broader than the web. Browsers offer APIs to JavaScript (the DOM, fetch, geolocation), operating systems offer them to apps, and libraries offer functions. Web APIs come in several styles: REST (resources and HTTP verbs), GraphQL (one endpoint where the client picks the fields), gRPC (fast binary calls between services) and webhooks, where the provider calls you when something happens.

Browsers apply the same-origin policy: a script on app.example.com cannot read a response from api.example.net, which stops a malicious page from quietly reading your email or bank account in another tab. CORS is how a server opts in. It sends headers such as Access-Control-Allow-Origin naming the sites allowed to read its responses, and for anything beyond a simple request (a PUT or DELETE, a JSON body, custom headers) the browser first sends an OPTIONS 'preflight' request to ask permission.

CORS is enforced only by browsers. Servers, scripts and tools such as curl ignore it, so it is not a security wall around an API; authentication does that job. The fix for a CORS error belongs on the server: allow the specific front-end origin rather than '*', especially when cookies are involved, where a wildcard is not allowed anyway.

Caches sit at every layer. The browser keeps images, scripts and pages according to the Cache-Control header; a CDN keeps copies in data centres near visitors; the server caches rendered pages or API results; and a store such as Redis holds the results of slow database queries. Each hit saves time, bandwidth and money.

The hard part is freshness. Lifetimes (max-age), revalidation (an ETag and a 304 'not modified' reply) and fingerprinted file names such as app.3f9a1c.js let files be cached for a year yet replaced the moment they change. Anything personal, such as a basket or an account page, must be marked private or no-store, or a shared cache could show one visitor's data to another.

When a browser loads HTML it builds a tree: the document contains html, which contains head and body, which contain headings, paragraphs and buttons, each a node with attributes, styles and text. JavaScript works on that tree through the DOM API, finding elements with calls such as document.querySelector, changing their text or classes, adding and removing them, and listening for events such as clicks.

Each change can make the browser recalculate styles and layout and repaint, which gets slow if done carelessly thousands of times. Frameworks manage this for you: React compares a 'virtual DOM' and applies only the differences, while Svelte compiles to direct, targeted updates. Screen readers work from an accessibility tree built from the DOM, and automated tests query it, so a well-structured DOM helps both.

Beyond the DOM, browsers expose dozens of APIs: fetch for network requests, Web Storage and IndexedDB for keeping data, Canvas and WebGL for drawing, Web Audio, WebRTC for calls, Geolocation, Clipboard, Notifications and Push, Web Share, and service workers for offline support. Together they let a web app do much of what once needed a native app.

Powerful features ask the user first (camera, microphone, location, notifications) and work only on HTTPS pages. Support varies between browsers and versions, so MDN and caniuse.com are the usual places to check before relying on one, along with a fallback for browsers that lack it.

A server sets a cookie with a Set-Cookie header, and the browser sends it back automatically on every later request to that site until it expires. That is how a site recognises you from page to page, since HTTP itself forgets. Each cookie holds only about 4 KB, and because cookies travel with every request, stuffing them with data slows the site down.

Attributes control the risks: HttpOnly hides a cookie from JavaScript, so an XSS attack cannot steal the session; Secure sends it only over HTTPS; and SameSite limits sending it from other sites, which blocks most CSRF attacks. Third-party cookies, set by a domain other than the one in the address bar, are how ad networks follow people across sites, and Safari and Firefox block or isolate them by default. In the EU and UK, non-essential cookies need consent first, which is why cookie banners exist.

Both store text keys and values for one site (strictly, one origin), through calls such as localStorage.setItem('theme', 'dark'). localStorage keeps data until the site or the user clears it; sessionStorage lasts only as long as the tab. Browsers allow about 5 MB per site, and anything that is not text, such as an object, has to be turned into a JSON string first.

The API is synchronous, so large reads and writes can briefly freeze the page, and it is not available in service workers; IndexedDB suits larger or structured data. Any script on the page can read it, so a cross-site scripting (XSS) bug exposes everything inside, which is why sign-in tokens are safer in an HttpOnly cookie. Nothing stored here is sent to the server automatically.

A JSON document looks like {"name": "Ada", "age": 36, "tags": ["admin"], "active": true}. It has only a handful of value types: strings, numbers, true and false, null, arrays (lists) and objects (name-value pairs). The syntax comes from JavaScript, but every mainstream language can parse it, which is why it replaced XML as the default format for web APIs.

Its simplicity has limits. There are no comments and no dates (they travel as text such as '2026-09-29T10:00:00Z'), binary data has to be encoded, and a single trailing comma makes a file invalid. Very large numbers lose precision in JavaScript, which is why IDs are often sent as strings. JSON Schema describes the shape a document should have, and databases such as PostgreSQL (JSONB) and MongoDB store it natively.

YAML holds the same kinds of data as JSON (lists, key-value maps, strings, numbers) but is designed to be read and written by hand: a key, a colon and a value on each line, nesting by indentation, dashes for list items and # for comments. YAML 1.2 is a superset of JSON, so a JSON document is also valid YAML. It is the usual format for CI pipelines, Docker Compose files, Kubernetes manifests, OpenAPI specs and many app settings.

The friendliness has traps. Indentation must use spaces, and one wrong level silently changes the meaning. Unquoted values are guessed: in parsers that follow the older YAML 1.1 rules, no, off and the country code NO become false (the 'Norway problem'), and a version number such as 1.10 becomes 1.1. Quoting strings avoids most of this, and a linter or schema check in the editor catches the rest.