Mar 26, 2025·8 min
Tim Berners-Lee’s Web: URLs, HTTP, HTML and Why It Matters
Learn how Tim Berners-Lee combined URLs, HTTP, and HTML to form the World Wide Web—and why these simple ideas still power modern apps and APIs.
Learn how Tim Berners-Lee combined URLs, HTTP, and HTML to form the World Wide Web—and why these simple ideas still power modern apps and APIs.
The World Wide Web (often just “the Web”) is a way of publishing and accessing information using links. It’s the system that lets you click from one page to another, open a product page from a search result, or share a link that works on almost any computer or phone.
At its core, the Web is powered by a practical trio:
You don’t need to be a programmer to feel their impact: every time you paste a link, load a page, or click a button that takes you somewhere, you’re leaning on URL + HTTP + HTML.
People often use “Web” and “Internet” interchangeably, but they’re different:
Email, online gaming, and many chat apps use the Internet without being “the Web” in the strict sense.
Even modern experiences—single-page apps, mobile apps, and APIs—still rely heavily on these foundations. They may hide the details, but they continue to use URLs to identify resources, HTTP to exchange requests and responses, and often HTML to bootstrap what you see in a browser.
Tim Berners-Lee wasn’t trying to invent “the internet.” In 1989, while working at CERN, he was focused on a practical frustration: important information existed, but it was scattered across incompatible systems, stored in different formats, and hard to find again later.
Researchers, teams, and departments used different computers and software. Even when two groups had the “same” kind of document, they might store it in different places, name it differently, or require a special program to open it. Sharing often meant sending files around, duplicating copies, and losing track of which version was current.
Berners-Lee’s core idea was to let anyone publish a document on their own computer, then let others access it using a consistent method—without needing to know the machine type, operating system, or internal directory structure.
That required a few things to work together:
The breakthrough wasn’t a single feature—it was the decision to keep the system small and universal. If the rules were simple enough, different computers and organizations could implement them and still communicate.
This is also why open standards mattered from the start: the web needed shared, public rules so that many independent systems could participate. That focus on common standards—rather than one vendor’s toolchain—made it possible for the web to spread quickly and for new browsers and servers to work with existing content.
If you’ve ever tried to “share a file” on a messy office drive, you’ve seen the core problem networks have: naming things consistently is hard. Different computers store information in different places, folders get reorganized, and two documents can have the same filename. Without a shared naming system, you can’t reliably say “get that thing over there.”
URLs solved this for the World Wide Web by providing a universal, copy‑and‑pasteable address for a resource.
Here’s an example you might recognize:
https://www.example.com:443/products/shoes?color=black&size=42#reviews
What each part means (in plain English):
A URL can identify almost anything a server can return: an HTML page, an image, a PDF, a downloadable file, or even an API endpoint used by an app.
For example:
/images/logo.png (an image)/docs/terms.pdf (a document)/api/orders/123 (data for an application)People often use these words interchangeably:
For practical purposes, thinking “URL = address” will get you 95% of the way there.
HTTP is the web’s basic conversation style. It’s a simple deal: your browser asks for something, and a server replies with what it has (or an explanation of why it can’t).
When you type a URL or click a link, your browser sends an HTTP request to a server. The request is like a note that says: “I want this specific resource.”
The server then sends back an HTTP response. The response is the package that contains the result: the content you asked for (like a page), or a message that something else happened.
HTTP requests include a method, which is just the kind of action you’re taking.
A GET usually doesn’t change anything on the server; it’s mainly for reading. A POST is commonly used when you’re sending information to be processed.
Every response includes a status code—think of it as the delivery outcome.
Requests and responses also include headers, which are like labels: “This is who I am,” “This is what I accept,” or “This is how this content should be handled.”
One of the most useful labels is the Content-Type, such as text/html for a web page or application/json for data. It tells the browser what’s inside so it can display it correctly.
HTML (HyperText Markup Language) is the format used to describe the structure of a web page—what the content is and how it’s organized. Think of it as a document with labels: “this is a heading,” “this is a paragraph,” “this is a link,” “this is a form field.”
HTML uses tags to mark up content. A tag usually has an opening and a closing version, wrapping the content it describes.
Headings and paragraphs give a page shape. A heading tells both people and browsers, “this is an important section title.” A paragraph tells them, “this is body text.”
Links and images are also described in HTML. An image tag points to an image file (a resource), while a link tag points to another URL.
The “HT” in HTML—hypertext—is the big idea that made the web feel different from earlier systems. Instead of navigating only by menus, file folders, or special commands, you could jump directly from one document to another using clickable links embedded in the text.
That shift sounds simple, but it’s powerful: knowledge becomes connected. A page can reference sources, related topics, definitions, and next steps instantly—no need to “go back” to a central index every time.
Here’s what a basic link looks like:
<a href="/blog/how-http-works">Read more about HTTP</a>
In plain language: “Show the words Read more about HTTP and, when clicked, take the reader to the page at /blog/how-http-works.”
HTML isn’t only for publishing documents. It can also describe inputs like text fields, checkboxes, and buttons. Those pieces let a page collect information (like a login, a search, or a checkout) and send it to a server.
It’s easy to mix these up, but they have different jobs:
Even as web apps have become more complex, HTML remains the starting point: it’s the shared, readable way to describe what a page contains—and where it can lead next.
When you visit a website, your browser is basically doing two jobs: finding the right computer to talk to, and asking for the right file.
A URL (like https://example.com/page) is the page’s address. It includes a host name (example.com) and often a path (/page).
Computers on the internet talk using numeric addresses called IP addresses. DNS (Domain Name System) is like a phone book that maps example.com to an IP address.
This lookup is usually quick—and sometimes it’s skipped because the answer is already stored from a recent visit.
Now the browser opens a connection to the server at that IP address. If the URL starts with https://, the browser also sets up an encrypted connection so others can’t easily read what’s being sent.
HTTP (Hypertext Transfer Protocol) is the “request-and-response” language of the web. The browser sends an HTTP request like: “Please give me /page.”
The server replies with an HTTP response that includes a status (like “OK” or “Not Found”) and the content.
That content is often HTML (HyperText Markup Language). HTML is a simple format that describes the structure of a page—headings, paragraphs, links, and more.
As the browser reads the HTML, it may discover it also needs other files (CSS for styling, JavaScript for interaction, images, fonts). It then repeats the same HTTP request/response pattern for each.
To speed things up, browsers keep a cache—a saved copy of files they’ve already downloaded. If nothing has changed, the browser can reuse that copy instead of downloading it again.
Quick checklist (the flow):
When people say “the web,” they often mean a smooth experience: you tap a link and a page appears. Underneath, it’s a simple relationship between three ideas: servers, browsers, and resources.
A server is a computer (or a cluster of computers) connected to the internet that hosts resources at URLs. If a URL is an address, the server is the place that receives visitors at that address and decides what to send back.
That “thing” the server sends might be a web page, a file, or data. The key point is that the server is set up to respond to requests for specific URLs.
A browser is a program (like Chrome, Safari, or Firefox) that fetches resources from servers and displays them in a human-friendly way.
When you enter a URL or click a link, the browser:
A resource is anything the web can identify and deliver at a URL. Common examples include:
This same model isn’t limited to browsers. A mobile app can also request a URL—typically a web API endpoint—and receive data to display in the app’s own interface. The roles stay the same: app as the “client,” server as the “host,” and the API response as the resource.
Early web pages mostly showed information. Forms are what let the web collect information—turning a page into a two-way conversation.
An HTML form is a structured set of fields (like text boxes, checkboxes, and buttons) plus two key instructions:
action URL)method, usually GET or POST)When you click “Submit,” the browser packages what you typed and sends it using HTTP to the server at that URL. That’s the bridge between “a document with fields” and “an application that processes input.”
At a high level:
So a search might look like /search?q=shoes (GET), while a checkout submission might POST order details to /checkout.
On the server side, a program receives the HTTP request, reads the submitted values, and decides what to do next:
The server then responds—often with a new HTML page (“Thanks!”), an error message, or a redirect to another URL.
If a form includes anything sensitive—passwords, addresses, payment details—HTTPS is essential. It prevents others on the network from reading or altering what’s being sent between your browser and the site. Without it, even a simple login form can expose users.
Modern “apps” on the Web aren’t just web pages. Most are web plus code: an HTML page that loads JavaScript and CSS, then uses that code to update what you see without constantly reloading the whole page.
Even when an app feels like a native program (infinite scrolling feeds, real-time updates, drag-and-drop), it still relies on the same three building blocks Tim Berners-Lee introduced.
A URL isn’t only for “a page.” It’s an address for any resource: a product, a user profile, a search query, a photo, or a “send message” endpoint. Good apps use URLs to make content shareable, bookmarkable, and linkable—core Web behavior.
Behind the scenes, apps send HTTP requests and receive HTTP responses, just like classic websites. The rules are the same whether you’re fetching an HTML page or loading data for part of the screen:
Most modern apps talk to APIs: URLs that return data—often JSON—over HTTP.
For example:
HTML still matters because it’s often the starting point (and sometimes the fallback). More broadly, the Web is a platform for integration: if systems can agree on URLs and HTTP, they can connect—no matter who built them.
A practical way to see these building blocks in action is to build something small—say, a React front end that talks to a JSON API and has shareable URLs for key screens. Tools like Koder.ai lean into this same model: you describe the app in chat, and it generates a standard web stack (React on the front end, Go + PostgreSQL on the back end), so you’re still working with real URLs, HTTP endpoints, and browser-delivered HTML—just with far less manual setup.
The Web works at global scale because it’s built on shared standards—public “rules of the road” that let different systems communicate reliably. A browser from one company can request a page from a server run by another, hosted anywhere, written in any programming language, because they agree on basics like URLs, HTTP, and HTML.
Without standards, every site would need a custom app to view it, and every network would have its own private way of sending requests. Standardization solves simple but critical questions:
When those rules are consistent, the Web becomes “mix and match”: any compliant browser + any compliant server = it works.
The impressive part is that standards can improve while the fundamentals stay recognizable. HTTP has moved from early versions to HTTP/1.1, then to HTTP/2 and HTTP/3, adding better performance and efficiency. Yet the core idea remains the same: a client requests a URL, a server responds with a status code, headers, and a body.
HTML has also grown—from simple documents to richer semantics and embedded media—while preserving the basic concept of pages and hyperlinks.
Much of the Web’s staying power comes from a strong preference for backwards compatibility. New browsers still try to render old pages; new servers still understand older HTTP requests. That means content and links can live for years—often decades.
If you want your site or app to age well, lean on standards-based design: use real URLs for shareable states, follow HTTP conventions for caching and status codes, and write valid HTML before adding extra layers. Standards aren’t restrictive—they’re what keep your work portable, dependable, and future-friendly.
Even if you use the web daily, a few terms get mixed up so often that they can quietly derail troubleshooting, planning, or even simple conversations. Here are common mix-ups—and the fastest way to correct them.
Misconception: The Internet and the World Wide Web are the same thing.
Quick fix: The Internet is the global network (cables, routers, connections). The Web is one service that runs on top of it, built from URLs, HTTP, and HTML.
Misconception: “My URL is example.com.”
Quick fix: example.com is a domain. A URL is a full address that can include the path, query, and more, like:
https://example.com/pricing (a specific route)https://example.com/search?q=shoes (a route plus a query)Those extra parts can change what the server returns.
Misconception: HTML and HTTP are interchangeable.
Quick fix: HTTP is the “delivery conversation” (request and response). HTML is one possible “package” delivered—often the one that describes a page and its links. HTTP can also deliver JSON data, images, PDFs, or video.
Misconception: Any error means “the site is down,” and redirects are always bad.
Quick fix: Status codes are signals:
Misconception: Every URL should open a human-readable page.
Quick fix: A URL can point to data (/api/orders), a file (/report.pdf), or an action endpoint for a form submission.
Misconception: If it’s HTTPS, the site is safe and honest.
Quick fix: HTTPS encrypts the connection and helps confirm you’re talking to the right domain—but it doesn’t guarantee the business is reputable. You still need to evaluate the source, content, and context.
Tim Berners-Lee’s core idea was surprisingly small: connect documents (and later, applications) using a shared addressing scheme, a shared way to request data, and a shared format to display and link it.
URL is the address. It tells you what you want and where it lives (and often how to reach it).
HTTP is the conversation. It’s the set of rules a browser and server use to ask for something and reply with it (status codes, headers, caching, and more).
HTML is the page format. It’s what a browser can read to render content—and, crucially, it’s where links connect one resource to another.
Think of the web like a simple three-step loop:
Once you have that loop in your head, modern details (cookies, APIs, single-page apps, CDNs) become easier to reason about: they’re usually refinements to naming, requesting, or rendering.
If you want to go a bit deeper without getting overly technical:
Understanding these basics pays off quickly: you’ll be better at evaluating web tools (“Does this rely on URLs and standard HTTP?”), communicating with developers, and troubleshooting everyday issues like broken links, caching surprises, or “404 vs 500” errors.
The Internet is the global network (routers, cables, IP routing) that connects computers. The Web is a service that runs on top of it: resources identified by URLs, transferred with HTTP, and often displayed as HTML.
Many things use the Internet without being “the Web,” like email, some multiplayer games, and many chat systems.
Think of a URL as a precise address for a resource. It can point to an HTML page, an image, a PDF, or an API endpoint.
A typical URL includes:
A domain (like example.com) is just the name of a host. A URL can include much more detail—like the path and query—that changes what you actually get back.
For example:
https://example.com/pricinghttps://example.com/search?q=shoesThe fragment (the part after #) is handled by the browser, not sent to the server in the HTTP request.
Common uses:
#reviews)If you change only the fragment, you often won’t trigger a full page reload.
HTTP is the rules for the request-and-response conversation between a client (browser/app) and a server.
In practice:
Use GET when you’re retrieving something (read-only in intent), like loading a page or fetching data.
Use POST when you’re submitting data to be processed, like creating an account, posting a comment, or starting a checkout.
A practical tip: if the action should be bookmarkable/shareable (like a search), GET is usually the better fit; if it changes server state, is typical.
Status codes summarize the outcome of a request:
When troubleshooting, a often points to a wrong URL or deleted page; a usually means a server-side bug or outage.
A browser needs an IP address to connect to a server. DNS is the system that translates a human name (like example.com) into an IP address.
If a site sometimes “doesn’t resolve,” DNS is a common suspect—especially if it fails on one network/device but works on another.
Caching is when your browser saves copies of previously downloaded resources so repeat visits load faster.
Practical implications:
Servers control a lot of caching behavior via HTTP headers (like cache lifetime and revalidation).
HTTPS encrypts traffic and helps ensure you’re connected to the intended domain, which protects logins, forms, and sensitive data in transit.
It does not guarantee the site is honest or safe. You still need to evaluate:
https) — how to access itexample.com) — which server/products/shoes) — which resource?color=black) — extra parameters#reviews) — a location within a page (browser-side)