What is a URL?

In the previous two courses, you built HTTP servers from scratch and learned how to validate data with Zod. Along the way, you typed URLs into your browser, passed them to fetch, and used them to define routes. But we never stopped to ask a basic question: what actually is a URL?

That changes now. Before we go any further, we need to understand the building blocks of every URL you’ll ever work with. This matters because as a backend developer, you’ll spend a huge amount of time reading URLs, constructing them, pulling data out of them, and routing requests based on them. If you don’t understand their structure, everything else becomes guesswork.

URL stands for Uniform Resource Locator. Every time you type something into your browser’s address bar, you’re writing a URL. It tells the browser exactly where to go on the internet and how to get there.

Breaking down a real URL

Let’s take a URL that uses every possible part and pull it apart piece by piece:

https://shop.example.com:443/shoes/sneakers?color=red&size=10#reviews

This looks like a single string, but it’s actually made up of six distinct pieces. Think of a URL like a home address. When you mail a letter, you need a street, city, state, and zip code. Each part tells the postal service where to deliver it. A URL works the same way for the internet.

Let’s go through each piece.

https:// the protocol

The very first part of the URL tells the browser how to communicate with the server.

• https:// means the connection is encrypted (secure). The “S” stands for “Secure.”
• http:// means the connection is not encrypted (insecure).

Think of it like choosing between a sealed envelope and a postcard. Both get delivered, but only one keeps the contents private.

shop.example.com the hostname

The hostname tells the browser which server to talk to. It’s the address of the machine on the internet that will handle your request.

• example.com is the domain name.
• shop is a subdomain, a sub-section of example.com.

You’ve seen this pattern before with things like mail.google.com or docs.google.com. Different subdomains can point to entirely different services, all under one domain.

:443 the port

A single server can run many services at the same time. The port number tells the browser which “door” to knock on.

• :443 is the default for HTTPS.
• :80 is the default for HTTP.

Because 443 is the default for HTTPS, you almost never see it written out. The browser fills it in automatically. You only see a port number when it’s something non-standard, like :3000 or :8080 during local development.

/shoes/sneakers the pathname

The pathname tells the server which specific resource you want. Think of it like navigating folders on your computer: go to the shoes folder, then grab sneakers.

When you define routes in @hectoday/http, the pathname is what the router looks at to decide which handler function should run. A request to /shoes/sneakers hits a different handler than a request to /hats/beanies.

?color=red&size=10 the search (query string)

The search string (also called the query string) carries extra data as key-value pairs. The ? marks where it starts, and each pair is separated by &.

Here, there are two parameters:

• color=red means “I want the color red”
• size=10 means “I want size 10”

This is how users send preferences, filters, pagination info, and other data through a URL. When someone visits /products?page=3, your server reads page=3 from the query string to know which page of results to return.

#reviews the hash (fragment)

The hash (also called the fragment) is a bookmark within the page. It tells the browser to jump to a specific section.

The full picture

Here’s the complete breakdown, all in one view:

  https://    shop.example.com   :443   /shoes/sneakers   ?color=red&size=10   #reviews
  ──┬───     ────────┬────────   ─┬──   ───────┬───────   ────────┬─────────   ───┬────
 protocol       hostname        port      pathname           search             hash

Every URL you’ll ever work with is made up of some combination of these parts. Most URLs don’t include a port or hash, but the structure is always the same.

Why should you care?

As a backend developer, you’ll work with URLs constantly:

• Fetching data from APIs means building URLs with the right path and query parameters.
• Reading query parameters means pulling values like ?page=3 out of the search string so your code knows what to do.
• Building links means constructing URLs to send users to the right place.
• Routing means looking at the pathname to decide which handler should process the request.

In the HTTP from Scratch course, you did some of this by hand, working with raw strings. That works, but it gets messy fast. JavaScript gives you powerful built-in tools (URL and URLSearchParams) to work with URLs cleanly and safely, with no messy string slicing needed. That’s exactly what we’ll start using in the next lesson.