I asked him what that was. He said "cURL" like it was obvious.

It wasn't obvious to me. I'd been building APIs for a few months and testing them by running my frontend, clicking buttons, and hoping the network tab in Chrome DevTools would show me something useful. Half the time it didn't, and I'd spend an hour not knowing whether the bug was in my frontend code or my backend.

That senior showed me in five minutes that I'd been doing it the hard way. This blog is the five-minute version I wish I'd had.

What Even is a Server?

Before cURL, let's talk about what we're actually talking to.

When you open Instagram, your phone doesn't have your feed stored locally. It sends a request to Instagram's servers — computers sitting in a data center somewhere — asking for your latest posts. Those servers process the request, fetch your data from a database, and send it back. Your app receives it and displays it.

This is the client-server model. Your phone is the client. Instagram's data center is the server. They talk to each other over HTTP — the same protocol your browser uses.

Here's the thing: your browser is a client. Postman is a client. Your mobile app is a client. And cURL? cURL is a client too — just a very stripped-down, terminal-based one.

What is cURL

cURL stands for Client URL. It's a command-line tool that lets you send HTTP requests to servers and see their responses. That's it.

No interface. No buttons. No project to set up. You type a command, you get a response. Done.

Programmers use cURL to:

• Test APIs they've built before writing frontend code
• Debug why a server is returning a certain response
• Check if an endpoint is even reachable
• Quickly inspect what a public API returns
• Automate HTTP requests in shell scripts

The reason it's worth learning isn't that it replaces Postman or your code. It's that it removes every layer between you and the server. No middleware, no framework, no library. Just your request and whatever comes back.

When something breaks and you don't know if it's your frontend, your backend, or the API you're calling — cURL isolates the answer immediately.

Your First cURL Command

Open your terminal. Type this:

curl https://httpbin.org/get

That's it. Press Enter.

You'll get back something like:

{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.88.1"
  },
  "origin": "49.206.12.87",
  "url": "https://httpbin.org/get"
}

You just made an HTTP GET request to a real server and got a real response. httpbin.org is a free service built specifically for testing HTTP requests — it echoes back information about the request you sent.

Look at what it returned:

• headers: The metadata your request carried — including User-Agent which shows you sent this as "curl" version whatever
• origin: Your public IP address
• url: The exact URL you requested

You didn't write any code. You didn't open a browser. You sent a network request from your terminal and read the response.

Understanding the Response

Let's slow down and understand what's happening when you make a request.

Every HTTP interaction has two parts: a request (what you send) and a response (what comes back).

The request has:

• A method — GET, POST, PUT, DELETE, etc. GET means "give me data." POST means "here's data, process it."
• A URL — where you're sending it
• Headers — metadata about the request (what format you accept, authentication tokens, etc.)
• A body — only relevant for POST and PUT requests, this is the actual data you're sending

The response has:

• A status code — a three-digit number that tells you what happened
• Headers — metadata about the response
• A body — the actual data returned, usually HTML or JSON

Status codes are the shorthand of HTTP. The ones you'll see constantly:

• 200 OK — worked perfectly
• 201 Created — your POST request created something
• 400 Bad Request — you sent something malformed
• 401 Unauthorized — you need to authenticate
• 404 Not Found — that resource doesn't exist
• 500 Internal Server Error — the server broke, not you

To see the status code and response headers with cURL, add the -i flag:

curl -i https://httpbin.org/get

Now you'll see the full response, headers first:

HTTP/2 200
content-type: application/json
...

{
  "args": {},
  ...
}

That first line — HTTP/2 200 — is the status code. 200 means success. Any time you're debugging and not sure if your request is even landing correctly, -i tells you immediately.

Making a GET Request to a Real API

GET requests are the simplest — you're asking for data, not sending any. Let's try a real public API.

curl https://api.github.com/users/torvalds

This fetches Linus Torvalds' GitHub profile via the GitHub API. You'll get back a JSON object with his username, follower count, public repository count, and more:

{
  "login": "torvalds",
  "name": "Linus Torvalds",
  "public_repos": 8,
  "followers": 240000,
  ...
}

No authentication, no setup. Just a GET request to a public endpoint. This is how you'd test any public API — skip Postman for a moment and just curl it.

If the JSON response is one long unreadable line, pipe it through python3 -m json.tool for pretty printing:

curl https://api.github.com/users/torvalds | python3 -m json.tool

Now it formats nicely with indentation.

Making a POST Request

POST is where things get interesting. GET fetches data. POST sends data.

When you submit a login form, fill out a survey, or create a new record via an API — that's POST. You're sending a body of data to the server and asking it to do something with it.

Here's how a POST request looks in cURL:

curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name": "Priyanshu", "role": "developer"}'

Let's break down what's new here:

-X POST tells cURL to use the POST method instead of GET (which is the default).

-H "Content-Type: application/json" adds a header. This tells the server: "The data I'm sending is JSON." Servers use this to know how to parse your body. If you send JSON without this header, many servers will reject it or misread it.

-d '{"name": "Priyanshu", "role": "developer"}' is the body — the actual data you're sending. The -d flag means "data".

The server at httpbin.org/post echoes back what you sent:

{
  "data": "{\"name\": \"Priyanshu\", \"role\": \"developer\"}",
  "headers": {
    "Content-Type": "application/json",
    ...
  },
  "json": {
    "name": "Priyanshu",
    "role": "developer"
  },
  ...
}

Your data arrived. The server parsed it as JSON. This is exactly what happens when your frontend sends data to your backend — cURL just makes the same thing happen from your terminal.

Using cURL to Talk to Your Own API

The real power of cURL for most developers is testing their own endpoints before writing frontend code.

Say you've built a simple Express server running locally:

# GET your data
curl http://localhost:3000/api/users

# POST new data
curl -X POST http://localhost:3000/api/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Test User", "email": "test@example.com"}'

Before writing a single line of React or any frontend code, you can verify your backend is working exactly as expected. The response tells you immediately: is the route registered? Is the data being parsed? Is the database connection working?

If the curl works and the frontend doesn't, the bug is in the frontend. If curl doesn't work either, the bug is in the backend. That isolation saves hours.

For endpoints that need authentication, pass the token in a header:

curl http://localhost:3000/api/profile \
  -H "Authorization: Bearer your_token_here"

Common Mistakes Beginners Make

Forgetting the Content-Type header on POST requests. If you send JSON data without -H "Content-Type: application/json", many servers won't parse the body correctly. You'll get confusing errors that look like the data isn't arriving. It is arriving — the server just doesn't know how to read it.

# Wrong - no Content-Type
curl -X POST http://localhost:3000/api/users \
  -d '{"name": "Test"}'

# Correct
curl -X POST http://localhost:3000/api/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Test"}'

Using single quotes on Windows. The examples in this blog use single quotes around JSON, which works perfectly on Linux and macOS. On Windows Command Prompt, single quotes aren't string delimiters — you need double quotes, and the inner quotes need escaping:

curl -X POST http://localhost:3000/api/users -H "Content-Type: application/json" -d "{\"name\": \"Test\"}"

Windows PowerShell handles this differently again. If you're on Windows and running into quote errors, this is almost certainly why.

Not checking the status code. A request can "complete" in cURL and still have failed at the HTTP level. If you get back a 401 or 404 response, cURL by default exits with status 0 (success) because the request itself completed — it's just the server said no. Use -i to always see the status code in your response.

Curling HTTPS URLs with certificate issues. Sometimes you'll hit a self-signed certificate on a development server and cURL refuses to connect. The temptation is to add -k (insecure) to bypass certificate verification. That's fine locally during development. Never do it in production scripts or with real credentials.

Assuming GET when you mean POST. cURL defaults to GET. If you forget -X POST on a POST request, you'll make a GET request to the same URL and get a confusing response that has nothing to do with your intended action.

The Four Flags You'll Use 90% of the Time

Most day-to-day cURL usage is some combination of these:

curl https://api.example.com/endpoint          # Simple GET
curl -i https://api.example.com/endpoint       # GET with response headers
curl -X POST https://api.example.com/endpoint \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'                        # POST with JSON body
curl -H "Authorization: Bearer token" \
  https://api.example.com/endpoint             # Authenticated GET

That's it. You don't need to memorise the entire cURL manual. These four patterns cover almost everything you'll need when building and debugging web applications.

Where to Go From Here

Once you're comfortable with GET and POST, cURL has a lot more to offer — file uploads, cookies, following redirects, saving responses to files, verbose mode to see the full request and response headers. But none of that matters until you're fluent with the basics.

The best way to get there is to replace Postman with cURL for a week whenever you're testing your own APIs. You'll get fast at it quickly, and you'll start to read HTTP interactions more naturally — which pays off every time you're debugging.

The terminal is your most honest interface to the web. cURL is how you use it.

cURL is one of those tools that feels minor until you internalise it. Then it becomes the first thing you reach for whenever something behaves unexpectedly over HTTP. Learn the four flags, use it on your own APIs, and everything else follows naturally.

I closed the tab immediately.

A year later, I actually sat down to learn it properly. And what surprised me most was how simple the rules are. Not the entire HTML spec — that's enormous. But the core idea. The mental model behind every tag and every element. Once that clicked, reading HTML source code went from intimidating noise to something I could actually parse.

This blog is that mental model. If you've never written HTML before, this is where you start.

What HTML Is

HTML stands for HyperText Markup Language. Ignore the name. Here's what it actually is.

Think about a physical newspaper. Before the design team adds fonts, colors, or layout — before any of that — a journalist writes the content. They mark up their article: "this is the headline", "this is the opening paragraph", "this is the pull quote", "this is the caption for the photo."

HTML does the same thing for webpages. It's a markup language that lets you describe the structure and meaning of content. "This is a heading", "this is a paragraph", "this is a link", "this is an image." No colors, no fonts, no animations — that's CSS's job. HTML just describes what things are.

Every webpage on the internet — every single one — has HTML as its foundation. When your browser loads google.com, it receives an HTML file, reads it top to bottom, and builds the page structure from it. CSS then styles it. JavaScript then adds interactivity. But the skeleton — the structure — is always HTML.

What an HTML Tag Is

An HTML tag is a label wrapped in angle brackets.

<p>

That's a tag. The p inside tells the browser what kind of element this is — in this case, a paragraph. The angle brackets < > tell the browser "this is a tag, not content."

Tags come in pairs. An opening tag marks where something starts:

<p>

A closing tag marks where it ends. It looks the same but has a forward slash before the name:

</p>

Everything you write in HTML uses this pattern. You open something, put content inside, and close it.

Think of tags like parentheses in a sentence — they wrap around something to say "this block belongs together." The opening tag is the left parenthesis, the closing tag is the right parenthesis. Your content goes in between.

Opening Tag + Content + Closing Tag = Element

Here's a distinction that confuses beginners for longer than it should: the difference between a tag and an element.

A tag is just the label itself — <p> or </p>.

An element is the full thing — the opening tag, the content, and the closing tag together.

<p>This is a paragraph.</p>

Here, <p> is the opening tag. </p> is the closing tag. This is a paragraph. is the content. The entire line — all three parts — is the element.

An analogy that helped me: a tag is like a bracket [ or ]. An element is like the full expression [sentence goes here]. The brackets alone aren't useful — they only make sense when they're wrapping something.

<!-- Tag: just the label -->
<h1>

<!-- Element: the whole thing -->
<h1>Hello, World!</h1>

When someone says "add a paragraph element to the page," they mean write the full <p>...</p> structure with content inside. When they say "the closing tag," they mean just the </p> part.

Simple distinction. Genuinely useful once you're reading error messages or documentation that refers to one or the other specifically.

Self-Closing Elements: The Tags With No Pair

Not every element has content between an opening and closing tag. Some elements don't have any content at all — they just exist and do their job.

These are called void elements or self-closing elements.

An image is a good example. The image itself is the content. There's no text to wrap:

<img src="photo.jpg" alt="A landscape photo">

No closing </img>. The element is complete on its own.

A line break is another:

<br>

You'll sometimes see these written with a trailing slash for XHTML compatibility:

<img src="photo.jpg" alt="A landscape photo" />
<br />

Both are valid in modern HTML. The important thing is knowing that these elements don't need — and shouldn't have — a separate closing tag.

Common void elements you'll use regularly:

<img>      — images
<br>       — line break
<hr>       — horizontal rule (a dividing line)
<input>    — form input field
<meta>     — page metadata in the <head>
<link>     — linking external resources like CSS files

Block-Level vs Inline Elements

Here's one of the most practically useful distinctions in HTML, and one that a lot of beginner resources skip over.

Elements in HTML behave in one of two ways when the browser renders them:

Block-level elements take up the full width of their container and always start on a new line. If you put two block elements next to each other in your HTML, they'll stack vertically.

Inline elements only take up as much width as their content needs. They don't force a new line. Multiple inline elements sit next to each other horizontally.

Here's a concrete example. <p> is a block element. <strong> is an inline element:

<p>I really <strong>love</strong> writing HTML.</p>

This renders as a single paragraph where the word "love" is bold. The <strong> element doesn't break the line — it just wraps around the word inline.

Compare that to two block elements:

<h1>Main Heading</h1>
<p>A paragraph below the heading.</p>

The heading and the paragraph each sit on their own line, stacked vertically — even if you wrote them on the same line in your HTML.

Why does this matter? Because understanding this behavior saves you from fighting the browser when you're trying to lay out a page. When something isn't sitting where you expect it, it's often because you're treating a block element like an inline element or vice versa.

Common block-level elements:

<div>     — generic container
<p>       — paragraph
<h1>–<h6> — headings
<ul>      — unordered list
<ol>      — ordered list
<li>      — list item
<section> — document section
<article> — self-contained content

Common inline elements:

<span>    — generic inline container
<a>       — link
<strong>  — important text (bold)
<em>      — emphasis (italic)
<img>     — image (technically inline by default)
<code>    — inline code

Commonly Used HTML Tags

Let me walk through the tags you'll reach for in almost every project.

Headings — <h1> through <h6>

Headings structure your content hierarchically. <h1> is the biggest, most important heading — typically the page title. <h6> is the smallest.

<h1>My Portfolio</h1>
<h2>Projects</h2>
<h3>Project One</h3>

Don't pick heading levels based on how big you want the text to look. Pick them based on hierarchy. Visual size is CSS's job. Heading level communicates meaning — to the browser, to screen readers, to search engines.

Paragraph — <p>

The most-used tag in any content-heavy page. Every block of text gets wrapped in <p>.

<p>This is the first paragraph on my about page.</p>
<p>This is the second paragraph. Browsers add spacing between them.</p>

Links — <a>

The "a" stands for anchor. The href attribute is where the link points:

<a href="https://github.com">Visit my GitHub</a>

Links are inline by default. You can put them inside paragraphs, headings, list items — anywhere.

Images — <img>

Two attributes are essential: src (the image path) and alt (a text description for screen readers and when the image fails to load):

<img src="profile.jpg" alt="Priyanshu smiling at a coffee shop">

Always write an alt attribute. It's not optional if you care about accessibility.

Div and Span — <div> and <span>

These are the generic containers — <div> for block-level grouping, <span> for inline grouping. They have no built-in meaning. Their entire purpose is to give you something to apply CSS classes or IDs to.

<div class="card">
  <h2>Blog Post Title</h2>
  <p>Preview text for the <span class="highlight">blog post</span> goes here.</p>
</div>

You'll use <div> constantly for layout. <span> is useful when you want to style a specific word or phrase within a larger block of text.

Lists — <ul>, <ol>, <li>

An unordered list renders as bullet points. An ordered list renders as numbered items. Both use <li> for each item:

<ul>
  <li>HTML</li>
  <li>CSS</li>
  <li>JavaScript</li>
</ul>

<ol>
  <li>Learn HTML</li>
  <li>Learn CSS</li>
  <li>Build something</li>
</ol>

A Simple Page Putting It Together

Here's what a minimal HTML page looks like with the tags above:

<!DOCTYPE html>
<html>
  <head>
    <title>My First Page</title>
  </head>
  <body>
    <h1>Hello, World</h1>
    <p>Welcome to my first HTML page. I built this <strong>from scratch</strong>.</p>

    <h2>Things I'm Learning</h2>
    <ul>
      <li>HTML</li>
      <li>CSS</li>
      <li>Git</li>
    </ul>

    <p>
      Check out my work on
      <a href="https://github.com">GitHub</a>.
    </p>

    <img src="desk.jpg" alt="My desk setup">
  </body>
</html>

Notice the structure: the <html> element wraps everything. Inside it, <head> holds metadata (like the page title that shows in the browser tab). <body> holds everything that actually renders on screen.

Every HTML page you write will have this skeleton.

Go Look at Real HTML Right Now

Here's something I'd encourage you to do before you close this tab: open any webpage — any one at all — right-click somewhere on the page, and click "Inspect" or "Inspect Element."

The panel that opens is your browser's DevTools. The "Elements" tab shows you the live HTML structure of that page. Click on any element in the panel, and the browser will highlight the corresponding section on the page.

Spend five minutes clicking around. Find a <div>, find a <p>, find an <a>. See how nested elements work. See what real HTML looks like at scale.

This is how I actually started understanding HTML. Not from reading — from inspecting things that already existed and figuring out why they were structured the way they were.

The browser's inspector is your best learning tool. And now you know enough to understand what it's showing you.

HTML is one of those things that feels big until you realise the core rules are just four: tags have angle brackets, elements are opening tag plus content plus closing tag, some elements are self-closing, and elements are either block or inline. Everything else builds on top of these four ideas.

I remember building a simple card component — a title, some text, a button, wrapped in a container. Nothing complex. It took me almost ten minutes to type it all out, and most of that time wasn't thinking. It was just... typing angle brackets.

Then a classmate watched me do this and said, very calmly: "Why aren't you using Emmet?"

He typed div.card>h2+p+button and hit Tab.

The entire card structure appeared. All the tags, properly nested, properly indented, in about half a second.

I sat there for a moment. Then I said: "What was that?"

This blog is the answer to that question.

What Emmet Is

Emmet is a plugin — built into VS Code by default, and available for almost every other code editor — that expands short abbreviations into full HTML (and CSS) code.

You type a short expression that describes the structure you want. You press Tab. Emmet writes the full HTML for you.

That's it. No installation needed if you're on VS Code. No configuration. No learning curve beyond the abbreviation syntax itself — which is the point of this blog.

Emmet isn't a programming language. It's not a framework. It's a shortcut system. And the shortcut system is designed to feel like the HTML structure you're trying to create — once it clicks, you'll be surprised how natural it feels.

Why Bother?

You might be thinking: I'm still a beginner. HTML isn't hard. Why add another thing to learn?

Fair question. Here's my honest answer.

You're going to type a lot of HTML. If you work on anything real — even a personal project — you'll write the same structural patterns over and over: wrapper divs, lists of items, cards, forms, nav bars. The mechanical part of typing those tags is not where your brain should be spending energy.

Emmet handles the typing. You handle the thinking.

It also helps you think about HTML structure more clearly. When you write ul>li*5, you're explicitly thinking "I need an unordered list with five items." That mental model is good for learning, not just for speed.

And practically: every professional frontend developer uses Emmet or something like it. Getting comfortable with it early means it'll be second nature by the time you're building real things.

How Emmet Works in VS Code

If you're on VS Code — which I'd recommend for everything in this series — Emmet is already installed and active for HTML files.

Open any .html file. Start typing an Emmet abbreviation. When you're done, press Tab. VS Code expands it.

That's the entire workflow. Type, Tab, done.

A few things worth knowing:

Emmet only activates in HTML (and other supported file types like JSX, Pug, etc.) by default. If you're in a .js file and Tab doesn't expand, that's why.

Sometimes VS Code shows a suggestion in the autocomplete dropdown — you can press Enter from there instead of Tab. Either works.

If Tab isn't expanding and you're definitely in an HTML file, check that Emmet is enabled: open VS Code settings (Ctrl+,), search for "Emmet: Enabled", and make sure it's on.

Now let's actually learn the syntax.

Basic Elements: Just Type the Tag Name

The simplest Emmet abbreviation is just the name of the HTML element you want, without the angle brackets.

Type this and press Tab:

p

Expands to:

<p></p>

Type this and press Tab:

h1

Expands to:

<h1></h1>

Type this and press Tab:

section

Expands to:

<section></section>

Your cursor lands between the opening and closing tags, ready for you to type the content. Clean, fast, no angle bracket typing.

This works for every standard HTML element. div, span, ul, button, form, header, footer, nav — all of them.

Adding a Class: The Dot

To add a class to an element, use a dot — exactly like CSS selectors.

Type:

div.container

Expands to:

<div class="container"></div>

Type:

p.intro-text

Expands to:

<p class="intro-text"></p>

Multiple classes? Keep adding dots:

div.card.featured

Expands to:

<div class="card featured"></div>

The reason Emmet uses dots for classes is intentional — it mirrors how you'd select that element in CSS (.container, .card). Once you know CSS selectors, you already half-know Emmet.

Adding an ID: The Hash

Same idea, but with a hash symbol for IDs:

div#main

Expands to:

<div id="main"></div>

Combine with a class:

div#app.wrapper

Expands to:

<div id="app" class="wrapper"></div>

Again — mirrors CSS selector syntax exactly. #app.wrapper in CSS would select an element with id "app" and class "wrapper". Emmet uses the same notation to create it.

Attributes: Square Brackets

For attributes beyond class and ID — like src, href, type, placeholder — use square brackets:

a[href="https://github.com"]

Expands to:

<a href="https://github.com"></a>

input[type="email" placeholder="Enter your email"]

Expands to:

<input type="email" placeholder="Enter your email">

Note that input is a void element (no closing tag), and Emmet knows this — it generates the correct self-closing form automatically.

img[src="photo.jpg" alt="My photo"]

Expands to:

<img src="photo.jpg" alt="My photo">

Nesting Elements: The > Operator

This is where Emmet starts to feel genuinely useful. The > operator creates a parent-child relationship — the element on the right is nested inside the element on the left.

div>p

Expands to:

<div>
  <p></p>
</div>

nav>ul>li

Expands to:

<nav>
  <ul>
    <li></li>
  </ul>
</nav>

That three-level structure typed as nine characters. Compare that to writing it by hand:

<nav>
  <ul>
    <li></li>
  </ul>
</nav>

Same result, fraction of the effort. And you're explicitly thinking about the hierarchy as you write the abbreviation — nav contains ul contains li.

Sibling Elements: The + Operator

The + operator creates sibling elements — elements at the same level, not nested.

h1+p

Expands to:

<h1></h1>
<p></p>

label+input

Expands to:

<label></label>
<input>

Combine with nesting:

div>h2+p+button

Expands to:

<div>
  <h2></h2>
  <p></p>
  <button></button>
</div>

A card with a heading, paragraph, and button — the structure my classmate showed me — in one abbreviation.

Repeating Elements: The * Operator

The * operator repeats an element a specified number of times.

li*3

Expands to:

<li></li>
<li></li>
<li></li>

ul>li*5

Expands to:

<ul>
  <li></li>
  <li></li>
  <li></li>
  <li></li>
  <li></li>
</ul>

Five list items, complete with the parent ul. Manually, that's 14 lines. With Emmet, it's seven characters.

Combine with classes:

div.card*3

Expands to:

<div class="card"></div>
<div class="card"></div>
<div class="card"></div>

Three identical card containers. One abbreviation.

Numbering Repeated Items: $

When you repeat elements, you often want sequential numbers. The $ placeholder inserts an auto-incrementing number.

li.item-$*3

Expands to:

<li class="item-1"></li>
<li class="item-2"></li>
<li class="item-3"></li>

h2.section-$*4

Expands to:

<h2 class="section-1"></h2>
<h2 class="section-2"></h2>
<h2 class="section-3"></h2>
<h2 class="section-4"></h2>

Useful for generating numbered sections, slides, or any sequentially-named elements during prototyping.

Adding Text Content: {}

To include text content inside the element, use curly braces:

p{Hello, World}

Expands to:

<p>Hello, World</p>

a[href="#"]{Click here}

Expands to:

<a href="#">Click here</a>

Combine with repetition and $:

li{Item $}*3

Expands to:

<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>

Now you're generating both the structure and the placeholder content at the same time.

Going Back Up: The ^ Operator

When you're chaining with >, you keep going deeper. The ^ operator lets you climb one level back up.

div>p>span^button

Expands to:

<div>
  <p><span></span></p>
  <button></button>
</div>

The ^ moves button up out of <p> and places it as a sibling of <p> inside <div>.

Honestly, once abbreviations get complex enough to need ^, I often split them into two separate abbreviations instead. But for simpler structures, it's useful to know.

Grouping: Parentheses

Parentheses group parts of an abbreviation — useful when you want to repeat a multi-element structure.

(div>h2+p)*3

Expands to:

<div>
  <h2></h2>
  <p></p>
</div>
<div>
  <h2></h2>
  <p></p>
</div>
<div>
  <h2></h2>
  <p></p>
</div>

Three identical card structures — each with a heading and paragraph — from one abbreviation. This is genuinely useful when scaffolding a page with repeated sections.

The Full HTML Boilerplate: !

And here's the one that comes up in every single project. Type this into a blank .html file and press Tab:

!

Just an exclamation mark.

Expands to:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>

</body>
</html>

A complete, valid HTML5 boilerplate. Everything you need to start a new HTML page: doctype declaration, <html> with language attribute, <head> with charset and viewport meta tags, a <title>, and an empty <body>.

One character. Tab. Full boilerplate.

This is the abbreviation I use literally every time I start a new HTML file. If you remember nothing else from this blog, remember ! followed by Tab.

A Real-World Example

Let me put several of these together into something resembling a real component. Say I want to scaffold a simple blog post card:

div.card>img[src="post.jpg" alt="Post image"]+div.card__content>h3{Post Title}+p{Post excerpt goes here.}+a[href="#"]{Read more}

Expands to:

<div class="card">
  <img src="post.jpg" alt="Post image">
  <div class="card__content">
    <h3>Post Title</h3>
    <p>Post excerpt goes here.</p>
    <a href="#">Read more</a>
  </div>
</div>

One line. A complete, structured blog card with an image, a content container, a heading, a paragraph, and a link. Every class, every attribute, properly nested.

That's the power of Emmet in practice.

Tips for Getting Comfortable

Type one abbreviation at a time and watch what it expands to. Don't try to memorise everything at once. The operators you'll use 90% of the time are >, +, *, ., #, and {}. Start with those.

Use ! every time you start a new HTML file. It'll become muscle memory within a week.

When you need a structure, try writing it in Emmet first. If it doesn't work the way you expect, fall back to typing it manually. No shame in that — Emmet is a tool, not a requirement.

The abbreviations in this blog cover what you'll actually use day to day. There's a full Emmet cheat sheet at docs.emmet.io if you ever want to explore the less-common syntax.

Emmet felt unnecessary until I started using it daily. Now typing raw HTML without it feels like writing code without autocomplete — technically possible, but slower than it needs to be. Learn the basics, use it on your next project, and it'll earn its place in your workflow.

The problem wasn't the CSS property. It was the selector.

I was trying to style the wrong thing, or targeting elements that didn't exist the way I thought they did. CSS selectors are how you tell the browser which elements your styles apply to — and getting them wrong means your styles go nowhere.

Once I understood selectors properly, CSS clicked. Not all of it, but enough. The styles started landing. The page started looking like what I intended.

This blog is the thing I wish I'd read before I wasted those hours.

Why Selectors Exist

CSS stands for Cascading Style Sheets. A stylesheet contains rules. A rule looks like this:

p {
  color: blue;
  font-size: 16px;
}

That rule has two parts: the selector (p) and the declarations (color: blue; font-size: 16px;).

The selector is the targeting mechanism. It answers the question: which elements on the page should receive these styles?

Without a selector, CSS has no idea where to apply your rules. A declaration without a selector is like a letter without an address — the content is there, but it has no idea where to go.

Think of selectors as different levels of addressing. If you're sending an announcement to everyone in a building, that's one kind of targeting. If you're sending a note specifically to the person in flat 3B, that's different — more specific, more precise. CSS selectors work the same way. Some target broadly. Some target exactly one element.

Let's go through them in order of specificity, starting with the broadest.

The Element Selector: Everyone with That Name

The element selector targets every instance of a particular HTML tag on the page.

p {
  color: #333;
  line-height: 1.6;
}

This applies color: #333 and line-height: 1.6 to every <p> element on the page. Every paragraph. All of them.

h1 {
  font-size: 2rem;
}

a {
  color: blue;
}

button {
  cursor: pointer;
}

Element selectors are the broadest kind. They're good for setting baseline styles — things you want to be consistent everywhere that tag appears. Font sizes for headings, base text color for paragraphs, default link colors.

The downside is exactly that broadness. If you want one paragraph to look different from all the others, the element selector can't help you. That's where class selectors come in.

The Class Selector: Grouped by Role

A class selector targets elements based on the class attribute in their HTML.

In your HTML:

<p class="intro">Welcome to my blog. This is the opening paragraph.</p>
<p>This is a regular paragraph with no special class.</p>
<p class="intro">Another intro-styled paragraph on a different page section.</p>

In your CSS:

.intro {
  font-size: 1.2rem;
  font-weight: 500;
  color: #1a1a1a;
}

The . before the name is what tells CSS "this is a class selector." Only elements with class="intro" receive these styles. The regular <p> in the middle is untouched.

Class selectors are the workhorse of CSS. They're reusable — the same class can be applied to as many elements as you want, and they'll all share those styles. They're flexible — you can add multiple classes to one element:

<div class="card featured">...</div>

.card {
  border: 1px solid #ddd;
  border-radius: 8px;
  padding: 20px;
}

.featured {
  border-color: #0070f3;
  background: #f0f7ff;
}

That <div> gets styles from both .card and .featured. Classes compose. You build small, focused style rules and combine them where needed.

This is how most modern CSS is written. Element selectors for baselines. Class selectors for components and variations.

The ID Selector: The Unique Target

An ID selector targets one specific element — the element with that exact id attribute.

In your HTML:

<header id="main-header">
  <nav>...</nav>
</header>

In your CSS:

#main-header {
  background: #0a0a0a;
  padding: 0 40px;
  height: 64px;
}

The # before the name marks it as an ID selector. Only the element with id="main-header" receives these styles.

The key difference between class and ID: an ID must be unique on the page. You can give the same class to dozens of elements. An ID should appear exactly once. It's an identifier — like a Social Security number for your HTML element. Every element can have one, but no two elements should share the same one.

Because of this uniqueness, ID selectors are typically used for major layout elements — the page header, the main content wrapper, the footer. Things that appear once.

Here's a comparison to make the three selectors concrete:

<!-- Element selector targets this and every other <p> -->
<p>Regular paragraph</p>

<!-- Class selector targets this and every other .highlight element -->
<p class="highlight">Highlighted paragraph</p>

<!-- ID selector targets ONLY this element -->
<p id="intro-text">The unique opening paragraph</p>

/* Targets all <p> elements */
p { color: #333; }

/* Targets all elements with class="highlight" */
.highlight { background: yellow; }

/* Targets only the element with id="intro-text" */
#intro-text { font-size: 1.3rem; }

Group Selectors: One Rule for Many

Sometimes you want the same styles applied to multiple different selectors. You could write separate rules:

h1 { font-family: 'Georgia', serif; }
h2 { font-family: 'Georgia', serif; }
h3 { font-family: 'Georgia', serif; }

Or you can group them with a comma:

h1, h2, h3 {
  font-family: 'Georgia', serif;
}

Same result. The comma means "apply this rule to each of these selectors." It works with any combination — element selectors, class selectors, ID selectors, mixed:

h1, .section-title, #page-heading {
  font-weight: 700;
  letter-spacing: -0.02em;
}

Group selectors are purely a convenience. They reduce repetition. If you find yourself writing the same declarations across multiple separate rules, group them.

Descendant Selectors: Targeting by Context

Sometimes you don't just want to target an element — you want to target an element only when it's inside another specific element.

That's what descendant selectors do.

article p {
  line-height: 1.8;
  margin-bottom: 1rem;
}

The space between article and p is the descendant combinator. This rule applies to <p> elements that are inside an <article> element. A <p> that's outside of an <article> is not affected.

Here's a concrete scenario. You have a navigation bar and a main content area. Both contain links. But you want navigation links to look different from content links:

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
</nav>

<main>
  <p>Read more about this in <a href="/docs">the documentation</a>.</p>
</main>

/* All links - base style */
a {
  text-decoration: none;
}

/* Links inside nav only */
nav a {
  color: white;
  font-weight: 600;
  padding: 8px 16px;
}

/* Links inside main only */
main a {
  color: #0070f3;
  text-decoration: underline;
}

The two nav a and main a rules apply to completely different sets of links, even though both target <a> elements. The context — where the link lives — determines which style it gets.

Descendant selectors don't have to be just one level deep. nav ul li a would target links that are list items inside an unordered list inside a nav. The descendant relationship can be any number of levels deep.

Selector Priority: When Rules Conflict

Here's something that tripped me up constantly when starting out. What happens when two CSS rules target the same element with conflicting styles?

p {
  color: black;
}

.intro {
  color: blue;
}

<p class="intro">Which color is this?</p>

That paragraph has both a <p> tag and a class of intro. Both rules apply to it. Both set a color. Which one wins?

The answer is blue — the class selector wins. This is called specificity, and the rule is straightforward at this level:

ID selectors beat class selectors. Class selectors beat element selectors.

Think of it as a ranking:

ID selector      → highest priority
class selector   → medium priority
element selector → lowest priority

More specific selectors override less specific ones, regardless of the order in the stylesheet. If you write an element selector after a class selector targeting the same property, the class selector still wins.

/* Even though this comes second, the class selector above still wins */
p {
  color: black;    /* loses to .intro */
}

.intro {
  color: blue;     /* wins over p */
}

And an ID selector would beat both:

p { color: black; }       /* loses */
.intro { color: blue; }   /* also loses */
#hero-text { color: red; } /* wins */

<p class="intro" id="hero-text">Red text</p>

This is a very high-level view of specificity — there's more to it when you get into combined selectors and the !important declaration. But for the selectors covered in this blog, this ranking is all you need.

Putting It Together

Let's look at a small real example that uses all the selector types from this blog:

<header id="site-header">
  <nav>
    <a href="/">Home</a>
    <a href="/blog" class="active">Blog</a>
    <a href="/about">About</a>
  </nav>
</header>

<main>
  <h1>Recent Posts</h1>
  <article class="post">
    <h2>Post Title</h2>
    <p class="excerpt">A short preview of the post content.</p>
  </article>
  <article class="post">
    <h2>Another Post</h2>
    <p class="excerpt">Another short preview.</p>
  </article>
</main>

/* Element selector - all h1s */
h1 {
  font-size: 2rem;
  margin-bottom: 1.5rem;
}

/* ID selector - only the site header */
#site-header {
  background: #0a0a0a;
  padding: 16px 40px;
}

/* Class selector - all nav links marked active */
.active {
  color: #0070f3;
  font-weight: 600;
}

/* Group selector - h1 and h2 together */
h1, h2 {
  font-family: 'Georgia', serif;
}

/* Descendant selector - only links inside the nav */
nav a {
  color: white;
  text-decoration: none;
  margin-right: 24px;
}

/* Class selector - excerpt paragraphs */
.excerpt {
  color: #666;
  font-size: 0.95rem;
}

Seven CSS rules. Every type of selector we covered. Each one targeting a specific group of elements for a specific reason.

Selectors Are the Foundation

Everything you do in CSS starts with a selector. Color, spacing, typography, layout — none of it applies until you've correctly targeted the elements you want to style.

Getting selectors right is the difference between CSS that works and CSS that sits in your file doing nothing. Once you're comfortable with element, class, ID, group, and descendant selectors, you have the foundation to style basically anything.

The next step after this is pseudo-classes (a:hover, li:first-child) and pseudo-elements (::before, ::after) — but those build directly on top of what we covered here. Selectors first. Everything else follows.

A quick way to practice: open your browser DevTools, click on any element on any webpage, and look at the "Styles" panel on the right. You'll see exactly which CSS rules are applying to that element, and which selectors targeted it. That panel is the best way to understand how selectors work in practice — someone else's CSS, live, showing you the targeting in real time.

Half the class said TCP. "It's reliable," someone explained confidently. "You want to make sure all packets arrive."

The professor shook his head. "You'd use UDP."

Confused silence.

"But what if packets get lost?" someone asked.

"In a live video call, you'd rather drop a frame than freeze the call waiting for a lost packet to be resent."

That was the moment TCP vs UDP stopped being abstract terms and became a real engineering decision. And that's what this blog is about — not what these protocols are at a byte level, but how they behave, when to choose one over the other, and how HTTP fits into all of this.

The Internet Needs Rules for Sending Data

Before TCP or UDP, let's talk about the problem they both solve.

When you send data across the internet, it doesn't travel as one big chunk. It gets broken into small pieces called packets. Each packet travels independently — possibly through different routes — and gets reassembled at the destination.

This creates problems. Packets can arrive out of order. They can get lost entirely. They can arrive corrupted. The internet's physical infrastructure doesn't guarantee anything — it's what networking people call a best-effort network.

TCP and UDP are two different answers to this chaos. Two protocols that sit on top of the internet's physical layer and impose different sets of rules on how data moves.

One chooses safety. The other chooses speed. Neither is wrong. They just solve different problems.

TCP: The Safe, Reliable Option

TCP stands for Transmission Control Protocol. The word that matters most here is control.

Before TCP sends a single byte of your actual data, it does a handshake — a three-step greeting between your computer and the server:

1. Your computer sends: "I want to connect." (SYN)

2. Server responds: "Okay, connection acknowledged." (SYN-ACK)

3. Your computer confirms: "Got it, let's go." (ACK)

Now the connection is established. Only then does data start flowing.

And as data flows, TCP does more work:

• Acknowledgements: Every packet sent gets acknowledged by the receiver. "Got packet 1. Got packet 2. Got packet 3." If the sender doesn't receive an acknowledgement in time, it assumes the packet was lost and resends it.

• Ordering: Packets arrive in the correct sequence even if they traveled different routes and arrived out of order.

• Flow control: TCP monitors how fast data is being sent and slows down if the receiver is getting overwhelmed.

• Error checking: Corrupted data gets detected and discarded, triggering a resend.

Think of TCP as a courier service with tracking. You hand over a package. The courier gives you a receipt. At every step, there's confirmation. If the package gets lost in transit, the courier goes back, gets a new one, and tries again. The package will arrive, intact, in the right order. You just have to wait for it.

The tradeoff? All that reliability adds overhead. More round trips. More waiting for acknowledgements. More latency.

UDP: The Fast, Fire-and-Forget Option

UDP stands for User Datagram Protocol. No handshake. No acknowledgements. No ordering. No guaranteed delivery.

You send a packet. It either arrives or it doesn't. You have no way of knowing which.

That sounds terrible until you think about when it's actually fine — even preferable.

Think of UDP as a radio broadcast. The station transmits. Whatever reaches your radio, reaches it. If there's static and you miss a word, the station doesn't stop and replay it. The broadcast just continues. You hear what you hear.

UDP is:

• Connectionless: No handshake required. Data starts flowing immediately.

• Unreliable: No acknowledgements. Packets can be lost, duplicated, or arrive out of order.

• Fast: Less overhead means less latency.

• Lightweight: No connection state to maintain on either end.

For situations where speed matters more than completeness, UDP wins. For situations where every single byte matters, TCP wins.

The Key Differences, Side by Side

When to Use TCP

Use TCP whenever losing data is unacceptable.

Web browsing: When you load a webpage, every byte of HTML, CSS, and JavaScript needs to arrive correctly. A missing chunk of your CSS file would make the page look broken. HTTP — which powers all web communication — runs on top of TCP for this reason.

File transfers: Downloading an image, a PDF, or a zip file. One missing or corrupted packet and the file is useless. FTP and SFTP both use TCP.

Email: SMTP, IMAP, POP3 — all TCP. Every word of every email needs to arrive.

Database connections: When your application talks to a PostgreSQL or MySQL server, that connection runs over TCP. Losing a query or a result mid-transfer would cause data corruption.

SSH: Remote terminal sessions need every character to arrive in the right order. You can't have commands arriving scrambled.

The pattern: any time you're transferring data where partial delivery is worse than slow delivery, TCP is the right call.

When to Use UDP

Use UDP when speed and real-time delivery matter more than perfection.

Live video and audio calls: Zoom, Google Meet, WhatsApp calls — all UDP. If a packet is lost during a video call, you see a brief glitch. That's far better than the alternative: TCP would pause the stream and wait for the lost packet to be resent, causing a freeze. A one-second freeze in a call is worse than a one-frame glitch.

Online gaming: In a multiplayer game, your character's position needs to be updated many times per second. If a position update from 200ms ago gets lost, you don't want to wait for it. You want the current position. Old data is worthless in real-time games.

Live streaming: YouTube Live, Twitch — UDP-based. A dropped frame in a live stream is invisible to the viewer. Waiting to resend it would cause buffering, which is far more disruptive.

DNS queries: Small, fast lookups. If a DNS query gets lost, the client just sends another one. The overhead of a TCP connection for something this small would be wasteful.

IoT sensors: Temperature sensors, GPS trackers — sending small, frequent updates where missing one reading is fine as long as the next one arrives.

The pattern: real-time data where a late packet is as useless as a lost one.

A Real-World Comparison

Let me make this concrete with a scenario I think about a lot: building two different features in the same app.

Feature 1: User uploads a profile picture. This needs TCP. If three packets from the image data arrive and one is missing, the image is corrupted. We can't show a broken image. We need every byte, in order, guaranteed. We wait. We retry. We use TCP.

Feature 2: Live location sharing in a delivery app. This needs UDP. The driver's GPS coordinates update every second. If the update at 2:00:01 PM gets lost, I don't want to wait for it. By the time it would be resent, the driver has already moved. I want the 2:00:02 PM update. Old location data is useless. Use UDP.

Same app. Same backend. Different transport protocols for different features, based on what each feature actually needs.

What is HTTP and Where It Fits

This is where a very common confusion lives.

People often talk about HTTP and TCP in the same breath, or use them interchangeably in casual conversation. They're not the same thing. They exist at different layers and do different things.

HTTP — HyperText Transfer Protocol — is an application-layer protocol. It defines how requests and responses are formatted when a browser communicates with a web server. When your browser wants an HTML page, it sends an HTTP request:

GET /index.html HTTP/1.1
Host: myportfolio.tech
Accept: text/html

The server receives this, processes it, and sends back an HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html

<html>...</html>

HTTP defines the format of these messages — the method (GET, POST, PUT), the headers, the status codes (200 OK, 404 Not Found, 500 Server Error), the body. It's a language that browsers and servers agreed to speak.

What HTTP does not do: it has no idea how to actually move bytes from your browser to the server and back. It doesn't handle packet splitting, sequencing, acknowledgements, or retransmission. That's not its job.

That's TCP's job.

The Relationship Between HTTP and TCP

HTTP runs on top of TCP. When a browser makes an HTTP request, the sequence goes like this:

1. TCP does the transport work first. A connection is established via the three-way handshake. A reliable channel now exists between the browser and the server.

2. HTTP uses that channel. The browser sends its HTTP request through the TCP connection. The server sends its HTTP response through the same TCP connection.

3. TCP ensures delivery. If any packet gets lost in transit, TCP handles the retransmission. HTTP never knows this happened. From HTTP's perspective, it just handed data to TCP and received data from TCP.

Think of it in layers:

Your browser (HTTP)
    ↓  "GET /index.html"
TCP (transport layer)
    ↓  establishes connection, guarantees delivery
IP (internet layer)
    ↓  routes packets across networks
Physical network
    ↓  actual cables, wireless signals
Server

HTTP is the language. TCP is the postal system that reliably delivers the letters. They're partners — each doing a job the other doesn't.

This is why "Is HTTP the same as TCP?" is a bit like asking "Is English the same as sound waves?" No — English is what you say, sound waves are how your voice travels through air to reach someone's ears. HTTP is what you send, TCP is how it gets there reliably.

HTTP/3 Changed This — Briefly

Worth a quick mention: HTTP/3, the latest version of HTTP, switched from TCP to QUIC — a protocol built on top of UDP. The goal was to reduce the latency that TCP's handshake and reliability mechanisms add.

QUIC reimplements reliability on top of UDP, but smarter — if one data stream is blocked (a slow CSS file), it doesn't block other streams (your HTML, your images). TCP's reliability is connection-wide; QUIC's is per-stream.

The foundational mental model stays the same: HTTP is the application layer, and whatever carries it — TCP or QUIC — is the transport layer below.

The Short Version

If you had to summarise this blog in four sentences:

TCP is reliable but adds overhead. UDP is fast but drops packets. Use TCP when you can't afford to lose data. Use UDP when you can't afford the delay of waiting for lost data.

HTTP is the language browsers and servers speak. TCP is the infrastructure that carries those conversations reliably. They operate at different layers and do different jobs. Neither replaces the other.

Networking protocols feel abstract until you start building things that depend on them. Understanding TCP vs UDP stops being academic the first time you have to decide why your video stream freezes or why your file download corrupted. The answer is almost always in the transport layer.

The problem was a firewall rule blocking TCP port 5432.

When I explained this to him, he asked: "So TCP is just about ports?"

It's not. Not even close. TCP is one of the most carefully designed protocols in computing, and understanding it properly changes how you debug, how you design systems, and how you reason about what "reliable" actually means in networking.

This blog is about what TCP does under the hood — not at the byte level, but at the behavioral level. What it negotiates before sending a single byte of your data. How it tracks every packet. How it handles loss. How it closes gracefully.

What is TCP and Why It Exists

The internet is, at its core, unreliable. Packets travel through routers they've never met, across cables they can't predict, arriving (or not) in orders that weren't planned. The physical network doesn't guarantee anything.

TCP — Transmission Control Protocol — is the answer to this unreliability. It's a protocol that sits on top of the internet's routing layer and adds a contract between two machines: "I promise that everything I send, you will receive, in order, without corruption. And if something goes wrong in transit, I'll fix it without you even knowing."

That's a big promise. Keeping it requires a lot of machinery — handshakes, sequence numbers, acknowledgements, retransmission timers. Let's go through each.

Problems TCP Is Designed to Solve

Before understanding the solution, let's understand the specific problems.

Packets arrive out of order. The internet routes packets independently. Packet 3 might arrive before packet 1 if it took a faster route. Your application would read garbled data if nobody reassembled them in the right sequence.

Packets get lost. Routers drop packets when congested. Wireless connections lose packets to interference. There's no built-in retry at the network layer.

Packets arrive corrupted. Bit flips happen. If a single bit flips in a file you're downloading, you want to detect it and get a clean copy — not silently accept broken data.

Sender overwhelms the receiver. If a powerful server blasts data at a slow device, the device's buffer overflows and packets are dropped. Someone needs to regulate speed.

No connection state. Without TCP, there's no concept of "is the other side even running?" You're just firing packets into the void.

TCP solves all of these. Let's see how it starts — with the handshake.

The 3-Way Handshake: Establishing Trust

Before a single byte of your application's data moves, TCP performs a 3-step ritual between the two machines. This is called the Three-Way Handshake, and it establishes the connection with mutual agreement.

Here's the best analogy I've found. Imagine you call a friend on the phone:

• You: "Hey, can you hear me?" (SYN)

• Friend: "Yeah, I can hear you. Can you hear me?" (SYN-ACK)

• You: "Yep, all good. Let's talk." (ACK)

Now both of you know the channel works in both directions. You didn't just assume. You verified. The conversation can begin.

TCP does exactly this, except both sides also exchange sequence numbers — a starting point for tracking packets — during this handshake.

Step-by-Step: SYN, SYN-ACK, ACK

Let's walk through it concretely. Your browser wants to connect to a web server.

Step 1 — SYN (Synchronise)

Your browser sends a TCP segment to the server with the SYN flag set. Alongside this, it sends its Initial Sequence Number (ISN) — a randomly chosen number, let's call it x.

What this says: "I want to connect. My sequence numbers will start at x. Are you there?"

The server receives this. The connection is now half-open on the server's side — it knows the client wants to connect, but hasn't confirmed it can yet.

Step 2 — SYN-ACK (Synchronise-Acknowledge)

The server responds with both the SYN and ACK flags set. It does two things:

• Acknowledges your SYN: "I received your request, and I'm expecting your next byte to have sequence number x+1."

• Sends its own Initial Sequence Number: y. "My sequence numbers will start at y."

What this says: "Got you. I'm here. Let's synchronise. Your data starts at x+1, mine starts at y."

Step 3 — ACK (Acknowledge)

Your browser sends back a final ACK:

• Acknowledges the server's SYN: "Got your sequence number y. Expecting y+1 next from you."

What this says: "Perfect. I heard you. We're both synchronised. Connection established."

Three messages. Both sides have confirmed the channel works in both directions. Both sides know each other's starting sequence numbers. The connection is live.

Client                          Server
  |                               |
  |  ------ SYN (seq=x) ------>   |
  |                               |
  |  <-- SYN-ACK (seq=y,ack=x+1)  |
  |                               |
  |  ------ ACK (ack=y+1) ----->  |
  |                               |
  |     Connection Established    |

This is why TCP connections have latency before data flows. The round trip of these three messages adds time. On a high-latency connection, this is measurable. It's one reason HTTP/3 moved to QUIC — QUIC can sometimes establish connections with zero round trips for returning clients.

How Data Transfer Works in TCP

Now the connection exists. Your browser starts sending your HTTP request. How does TCP handle the actual data?

Sequence Numbers and Acknowledgements

Every byte TCP sends has a sequence number. If the browser sends 1,000 bytes starting from sequence number 100, those bytes are numbered 100 through 1,099.

The receiver — the server — sends back an ACK for every segment received. The ACK number says: "I've received everything up to this point. Send me the next byte starting from this number."

If the server received bytes 100–1,099 successfully, it sends ACK 1100: "Got everything. Send me 1100 next."

This continuous loop — send, acknowledge, send, acknowledge — is how TCP tracks that data arrived safely.

Windowing: Not Waiting After Every Packet

Here's something that would otherwise make TCP impractically slow: if the sender had to wait for an ACK after every single packet, the round-trip time would dominate everything. You'd be waiting constantly.

TCP uses a sliding window to solve this. The sender can have multiple packets "in flight" simultaneously — sent but not yet acknowledged — up to a limit called the window size.

Think of it like ordering at a restaurant. You don't place one item, wait for it to arrive, eat it, then order the next. You order everything at once and it comes as it's ready. The window is how many dishes can be on their way to your table at the same time.

The window size can grow over time as the connection proves reliable — TCP starts conservatively and speeds up. This is called slow start, and it's the algorithm behind why your download often accelerates after the first second.

How TCP Ensures Reliability, Order, and Correctness

Handling Lost Packets: Retransmission

What happens if a packet is lost? The receiver simply doesn't send an ACK for it.

The sender has a retransmission timer ticking for every unacknowledged packet. If the timer expires and no ACK arrived, the sender assumes the packet was lost and resends it.

There's also a faster mechanism: duplicate ACKs. If the receiver gets packet 5 after already receiving packets 1, 2, 3, it ACKs the last successfully received in-order packet — say, ACK 3. If the sender gets three of these duplicate ACKs, it doesn't wait for the timer. It knows packet 4 is missing and retransmits immediately. This is called fast retransmit.

Your application never sees this. As far as HTTP or your database driver is concerned, the bytes just arrived. TCP handled the loss and recovery silently.

Ordering

Because every byte has a sequence number, the receiver can always put packets back in the right order regardless of when they arrived. Got packet 5 before packet 3? Buffer packet 5, wait for packet 3, reassemble in order, deliver to the application in sequence.

Error Detection: Checksums

Every TCP segment includes a checksum — a number computed from the data in that segment. The receiver recalculates this checksum and compares it to the received value. If they don't match, the segment is silently discarded. The sender's retransmission timer handles the rest.

Corruption detected. Bad data never reaches your application.

Flow Control

The receiver tells the sender how much buffer space it has left using a field called the receive window. If the receiver's buffer is filling up, it shrinks this window, signalling the sender to slow down. If the buffer empties, it expands the window.

This prevents a fast sender from overwhelming a slow receiver. The sender adapts its pace dynamically based on what the receiver can handle.

How a TCP Connection Is Closed

Closing a TCP connection is also a negotiated process — and it's four steps, not three. This is called the 4-Way Teardown (or FIN handshake).

Why four steps? Because TCP connections are full-duplex — both sides send data independently. Closing one direction doesn't close the other. Each side has to independently signal that it's done sending.

Client                          Server
  |                               |
  |  ------- FIN ------------>    |  "I'm done sending"
  |                               |
  |  <------ ACK -------------    |  "Got it"
  |                               |
  |  <------ FIN -------------    |  "I'm done sending too"
  |                               |
  |  ------- ACK ------------>    |  "Got it. Goodbye."
  |                               |
  |        Connection Closed       |

After the client sends FIN, it enters a TIME_WAIT state before fully closing. This wait (typically 2 minutes) ensures any delayed packets from the old connection don't confuse a new one using the same port. If you've ever restarted a server and gotten "Address already in use", that's TIME_WAIT.

The server can also send data after receiving a FIN from the client — that's what full-duplex means. The client said "I'm done sending", not "stop everything." The server might still have data to finish sending before it sends its own FIN.

Putting It All Together

Here's the full lifecycle of a TCP connection for a single HTTP request, start to finish:

1. 3-Way Handshake
   SYN → SYN-ACK → ACK
   (Connection established)

2. Data Transfer
   HTTP request sent with sequence numbers
   Server ACKs received segments
   Server sends HTTP response
   Client ACKs received segments
   (Retransmission happens if anything is lost)

3. 4-Way Teardown
   FIN → ACK → FIN → ACK
   (Connection closed gracefully)

Every HTTP request your browser makes goes through this. Every database query your application sends goes through this. Every SSH command you type goes through this.

What This Changes About How You Debug

When I told my friend his problem was a firewall blocking port 5432, he understood it differently after learning about the handshake. The firewall was dropping the SYN packet before it reached the database server. The handshake never completed. The connection never established. The Python driver kept timing out waiting for a SYN-ACK that would never come.

Once you understand the handshake, errors like "connection refused", "connection timed out", and "connection reset" stop being mysterious.

• Connection refused: The port is reachable but nothing is listening on it. The OS sends back a RST (reset) immediately.

• Connection timed out: The SYN went out but no SYN-ACK ever arrived. Firewall, wrong IP, server unreachable.

• Connection reset: Something sent a RST mid-connection — often a firewall or a server that forcibly closed the connection.

The handshake is the diagnostic entry point. If it doesn't complete, nothing else matters. And now you know exactly what to look for.

TCP is one of those protocols that rewards understanding. You don't interact with it directly as an application developer — it's invisible by design. But when things go wrong at the network level, it's almost always the handshake that tells you why.

Then in my second year, my professor asked us to explain what happens between pressing Enter and seeing the page. I said something like: "The browser fetches the HTML and shows it." He nodded slowly in that way professors do when they're being polite about a terrible answer.

The real answer took me weeks to piece together. And once I did, I genuinely started looking at browsers differently — not as windows, but as some of the most sophisticated software ever built. Your browser does more work in two seconds than most programs do in their entire lifetime.

Let me walk you through it. We'll go layer by layer, no specification pages, no jargon avalanches. Just how it actually works.

What a Browser Actually Is

Most people describe a browser as "software that opens websites." That's like calling a car "a seat that moves." Technically accurate. Completely misses the point.

A browser is a platform — a complex application that fetches resources from the internet, interprets multiple programming languages simultaneously, constructs a visual representation of those resources, and renders it on your screen, all while handling user interactions in real time.

It speaks HTTP to fetch files. It understands HTML, CSS, and JavaScript. It has its own layout engine, rendering pipeline, JavaScript runtime, and networking stack. It manages memory, security sandboxes, and multiple processes running in parallel.

All of that fires up every time you type a URL.

The Main Parts, Before We Dive In

Before going deep, here's the high-level map. Think of a browser as a team where each member has one job:

User Interface (UI): Everything you see and interact with that isn't the webpage itself. The address bar, the tabs, the back button, the bookmarks bar.

Browser Engine: The coordinator. Takes input from the UI, passes it to the rendering engine, manages communication between components.

Rendering Engine: The core worker. Takes HTML, CSS, and other resources and figures out what to draw on screen.

Networking Layer: Handles all HTTP/HTTPS requests — fetching HTML files, CSS files, images, JavaScript.

JavaScript Engine: Parses and executes JavaScript. Chrome uses V8. Firefox uses SpiderMonkey.

Data Storage: Cookies, localStorage, IndexedDB, cache — the browser's memory for persistent data.

These components hand work to each other in a pipeline. Understanding that pipeline is what this blog is about.

The User Interface: The Part You Know

The UI is everything you interact with before the webpage loads — address bar, back/forward buttons, reload, bookmarks, tabs.

The UI and webpage content are intentionally separated. The browser's address bar is not part of the webpage. This matters for security — a website can't fake your browser chrome to spoof URLs (at least not through normal means).

When you type a URL and press Enter, the UI hands that URL to the browser engine. That's when the real work starts.

Browser Engine vs Rendering Engine

These two get confused constantly, even in technical writing. Here's the simple version:

The browser engine is the glue. It sits between the UI and the rendering engine, coordinating communication. When you press back, it's the browser engine that tells the rendering engine to load the previous page. It manages navigation, history, and coordinates between components.

The rendering engine is the builder. It takes raw HTML and CSS and converts them into something visual. This is where your webpage actually gets constructed and drawn.

Different browsers use different rendering engines:

• Chrome and Edge use Blink

• Firefox uses Gecko

• Safari uses WebKit (Blink was actually forked from WebKit)

You don't need to memorize which engine does what internally. The important thing is understanding the flow that all of them follow. That flow is remarkably similar across every browser.

Networking: Fetching the Raw Material

You pressed Enter. The networking layer takes over.

DNS resolution happens first — the domain gets converted to an IP address (exactly what we covered in the DNS resolution blog: root → TLD → authoritative nameserver). Then the browser opens a TCP connection to that IP and sends an HTTP request:

GET /index.html HTTP/1.1
Host: google.com
Accept: text/html

The server responds with the HTML file as a stream of bytes. The browser starts working on it immediately, even before the full file arrives.

While parsing HTML, the browser discovers more resources — a CSS file in <link>, JavaScript in <script>, images in <img>. Each triggers another network request. Modern browsers have a preload scanner that reads ahead in the HTML while the main parser is busy, fetching CSS and JS files early so requests overlap instead of queue up.

HTML Parsing: Building the DOM

The raw HTML the browser receives is just text. A string of characters. The browser needs to make it meaningful.

This process is called parsing. Let me explain parsing with something simpler first.

Consider this math expression: 3 + 4 × 2

You don't evaluate it left to right. You know multiplication comes before addition. You understand the structure — the rules — and evaluate accordingly: 3 + 8 = 11.

Parsing is the same idea. Take a flat sequence of characters, understand the rules of the language, and extract the structure.

For HTML, the parser reads character by character, identifies tags, attributes, and text content, and converts them into a structured tree. Take this HTML:

<html>
  <body>
    <h1>Hello World</h1>
    <p>This is a paragraph.</p>
  </body>
</html>

The parser turns this into a tree structure:

Document
└── html
    └── body
        ├── h1
        │   └── "Hello World"
        └── p
            └── "This is a paragraph."

This tree is called the DOM — Document Object Model. Every element in your HTML becomes a node in this tree. Every piece of text becomes a node. Even HTML comments become nodes.

The DOM is not your HTML file. It's a live, in-memory tree representation that the browser builds from your HTML. This is an important distinction. When JavaScript manipulates the DOM with document.querySelector() or element.innerHTML, it's operating on this tree in memory — not modifying your actual HTML file.

One thing I found interesting: HTML parsing is intentionally forgiving. If you write broken HTML, the parser doesn't crash. It makes its best guess and continues. That's why badly-written HTML often still renders — the browser is quietly fixing your mistakes.

CSS Parsing: Building the CSSOM

While HTML is being parsed (or sometimes after, depending on where your <link> tag is), the browser fetches and parses CSS files.

CSS parsing works similarly to HTML parsing but produces a different tree — the CSSOM, which stands for CSS Object Model.

Take this CSS:

body {
  font-size: 16px;
}

h1 {
  color: blue;
  font-size: 32px;
}

p {
  color: gray;
}

The browser parses these rules and builds a tree where styles cascade down from parent elements to children. This is what the "Cascading" in Cascading Style Sheets actually means — styles inherit and override as you go down the tree.

Here's something important that tripped me up early: CSS blocks rendering. The browser will not render the page until it has fetched and parsed all CSS files. It needs the complete CSSOM before it can draw anything, because any CSS file could override any style.

This is why putting <link rel="stylesheet"> in the <head> matters. It gives the browser a chance to fetch CSS early. And it's why large, slow-loading CSS files make your page feel slow — the entire render is waiting for that CSS to arrive and be parsed.

Render Tree: DOM Meets CSSOM

Now you have two trees: the DOM (structure) and the CSSOM (styles). The browser combines them into a third structure called the Render Tree.

The Render Tree contains only the elements that will actually be visible on screen. It merges each DOM node with its computed styles from the CSSOM.

This is where some elements get excluded. <head> elements — <title>, <meta>, <link> — are in the DOM but not the Render Tree, because they don't render visually. Elements with display: none are also excluded — they're in the DOM, but they don't occupy space on screen.

Think of it this way:

• DOM = the full structure, including invisible elements

• CSSOM = the style rules

• Render Tree = visible elements with styles attached

The Render Tree is what the browser actually uses to figure out what to draw.

Layout (Reflow): Where Does Everything Go?

Having a Render Tree tells the browser what to draw. But not where.

That's the Layout stage (also called Reflow). The browser walks the Render Tree and calculates the exact position and size of every element in pixels. This <h1> is 960px wide, starts at x=20, y=80. This <p> is 920px wide, starts at x=20, y=140. Percentage widths become pixels. Flexbox and grid calculations happen here. Text wrapping is figured out.

Layout is expensive. It runs again (hence "reflow") any time something changes element positions — a DOM element added, a CSS class toggled, an image that loads and shifts the page. Minimizing reflows is one of the most fundamental frontend performance optimisations.

Painting: Filling in the Pixels

After layout, the browser knows where everything goes. Now it fills in the visuals — colors, text, shadows, borders, images. That's the Paint stage.

Modern browsers paint in layers. Animated or transformed elements get their own layers. These layers are then composited — combined by the GPU in the correct order — and displayed on screen.

This is why CSS transform animations are smoother than changing top/left — transforms happen at the compositing stage (GPU), not at the paint stage (CPU). Understanding this is the difference between 60fps animations and janky ones.

The Full Flow, Start to Finish

Let me bring it together. Type a URL, press Enter. Here's what happens:

URL entered
  → DNS resolution (domain → IP address)
    → TCP connection opened
      → HTTP request sent
        → HTML received and parsed
          → DOM built
        → CSS fetched and parsed
          → CSSOM built
        → DOM + CSSOM → Render Tree
          → Layout (calculate positions)
            → Paint (fill pixels)
              → Composite (combine layers)
                → Webpage visible ✓

Every request. Every page. Every time. On a fast connection with a simple page, this entire pipeline can run in under a second.

Where JavaScript Fits In

JavaScript complicates the timeline — in an interesting way.

When the HTML parser encounters a <script> tag, it stops. It pauses HTML parsing, fetches the JavaScript file, executes it, then resumes parsing. This is why you've heard "put your scripts at the bottom of <body>" — placing scripts in <head> would block the entire page from rendering until the script downloads and runs.

JavaScript can modify the DOM. document.createElement(), element.remove(), element.style.color = 'red' — all of these change the Render Tree, which can trigger new Layout and Paint stages. This is called a reflow and repaint, and doing it excessively is one of the main causes of janky, slow websites.

The async and defer attributes on script tags exist precisely to give you control over when JavaScript runs relative to HTML parsing — so you can avoid blocking the render pipeline unnecessarily.

What This Means for You as a Developer

Understanding browser internals doesn't mean you need to memorize every specification. But it does change how you write code.

Knowing that CSS blocks rendering explains why you should keep stylesheets lean and load them early. Knowing that DOM manipulation triggers reflows explains why batching DOM changes is faster than making them one at a time. Knowing that JavaScript blocks HTML parsing explains defer and async. Knowing that painting happens in layers explains why CSS transforms are more performant than changing top and left for animations.

Every performance tip you'll ever read about frontend development — lazy loading, critical CSS, script deferral, avoiding layout thrashing — traces back to one or more of these pipeline stages.

You don't have to be a browser engineer to benefit from knowing this. You just have to understand the flow.

Browsers are the most widely deployed, most used, and least understood piece of software in the world. Millions of people use them every day without ever thinking about DOM trees or render pipelines. But you're building things for browsers — and that's a good reason to understand what's happening on the other side of your code.

"What do you mean propagate? Where does it go?"

Nobody could explain it clearly. So I started digging — quite literally. There's a command called dig that shows you exactly how DNS resolution works, step by step, layer by layer. Once I understood what dig was telling me, DNS stopped being a black box entirely.

This blog walks through exactly what I learned: how DNS resolution actually works, and how to trace it yourself in your terminal.

What DNS Is (And Why Name Resolution Exists)

Quick recap first. DNS stands for Domain Name System. It translates human-readable domain names like google.com into machine-readable IP addresses like 142.250.185.46.

Computers don't understand google.com. They need an IP address to know where to send packets. But nobody wants to memorize 142.250.185.46. DNS solves this by being the internet's phonebook — you look up a name, it gives you the number.

But here's what most explanations skip: DNS isn't a single server somewhere that knows everything. It's a hierarchy — a tree of servers distributed across the planet, each responsible for different parts of the domain namespace. When your browser needs to resolve google.com, it doesn't ask one server. It works through a chain.

Understanding that chain is what this entire blog is about.

Meet dig: The DNS Diagnostic Tool

dig stands for Domain Information Groper (yes, really). It's a command-line tool that lets you manually query DNS servers and see exactly what they respond with.

Developers and system administrators use dig for:

• Debugging DNS issues (why isn't my domain resolving?)

• Verifying that DNS changes propagated correctly

• Checking what nameservers are authoritative for a domain

• Tracing the full DNS resolution path

• Inspecting specific record types

If you're on Linux or macOS, dig is almost certainly already installed. On Windows, you can use WSL or install it via BIND tools.

Basic syntax:

dig [domain] [record type]
dig [domain] [record type] @[nameserver]

We're going to use four specific dig commands that walk through the entire DNS resolution hierarchy, from the very top of the tree all the way down to the final answer.

Layer 1: dig . NS — The Root of Everything

Let's start at the absolute beginning. Run this in your terminal:

dig . NS

That dot (.) represents the root of the DNS hierarchy. Every domain name actually ends with a dot — google.com. — you just never type it. The root is above everything.

You'll get back something like:

;; ANSWER SECTION:
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  f.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  m.root-servers.net.

Thirteen root name servers. a.root-servers.net through m.root-servers.net.

These are the starting point for all DNS resolution on the internet. They don't know where google.com is — but they know who to ask next. Root servers know which servers are responsible for each TLD (Top-Level Domain): .com, .net, .org, .in, .dev, and every other extension.

Think of root servers as the head office of a massive postal network. They don't know your specific delivery address. But they know which regional office handles your area, and they'll point you there.

There are only 13 logical root server addresses, but each one is actually a cluster of hundreds of physical machines distributed globally (using a technique called anycast). So "13 root servers" doesn't mean 13 machines — it means 13 address identifiers, each backed by hundreds of servers worldwide. The whole system is designed to never go down.

The 518400 number in that output is the TTL — Time To Live — in seconds (518400 seconds = 6 days). DNS responses can be cached for this duration before needing a fresh lookup.

Layer 2: dig com NS — The TLD Layer

Now let's go one level deeper. We know root servers handle the top of the tree. The next layer down is the TLD layer. Run:

dig com NS

Output:

;; ANSWER SECTION:
com.    172800  IN  NS  a.gtld-servers.net.
com.    172800  IN  NS  b.gtld-servers.net.
com.    172800  IN  NS  c.gtld-servers.net.
com.    172800  IN  NS  d.gtld-servers.net.
com.    172800  IN  NS  e.gtld-servers.net.
com.    172800  IN  NS  f.gtld-servers.net.
com.    172800  IN  NS  g.gtld-servers.net.
com.    172800  IN  NS  h.gtld-servers.net.
com.    172800  IN  NS  i.gtld-servers.net.
com.    172800  IN  NS  j.gtld-servers.net.
com.    172800  IN  NS  k.gtld-servers.net.
com.    172800  IN  NS  l.gtld-servers.net.
com.    172800  IN  NS  m.gtld-servers.net.

These are the .com TLD nameservers, operated by Verisign. GTLD stands for Generic Top-Level Domain. These servers know about every registered .com domain — not what IP they point to, but which nameservers are responsible for them.

When you register a domain like myportfolio.com with GoDaddy or Namecheap, your registrar tells these .com TLD servers: "Hey, myportfolio.com is managed by these nameservers." That's the NS record we talked about in the DNS records blog.

So the TLD servers answer a very specific question: "For this .com domain, who is the authoritative nameserver?" They don't give you IPs. They hand you off to the next layer.

Think of TLD servers as regional post offices. The head office (root) says ".com? Go to the regional office for America." That regional office knows which local branch office handles your specific street, but doesn't know your exact house number.

If you want to try the same for a different TLD:

dig in NS     # India's TLD servers
dig dev NS    # .dev TLD servers
dig org NS    # .org TLD servers

Each TLD has its own set of authoritative nameservers managed by a different organization.

Layer 3: dig google.com NS — The Authoritative Layer

Now we're getting specific. Run:

dig google.com NS

Output:

;; ANSWER SECTION:
google.com.   345600  IN  NS  ns1.google.com.
google.com.   345600  IN  NS  ns2.google.com.
google.com.   345600  IN  NS  ns3.google.com.
google.com.   345600  IN  NS  ns4.google.com.

These are Google's own authoritative nameservers. These servers hold the actual DNS records for google.com — the A records, AAAA records, MX records, TXT records, everything.

The TLD servers for .com know that google.com is managed by ns1.google.com through ns4.google.com. So when someone needs to resolve google.com, the .com TLD servers say: "Go ask ns1.google.com."

These authoritative nameservers are the final stop. They give a definitive answer. There's no "ask someone else" at this layer — the buck stops here.

For your own domain, these would be your hosting provider's nameservers, Cloudflare's nameservers, or whatever you configured as your NS records. When you set up a website and point your domain to Cloudflare, you're telling the TLD servers: "Cloudflare's nameservers are authoritative for this domain now."

The word "authoritative" is important. A nameserver is authoritative for a domain if it's the designated final source of truth for that domain's DNS records. All other DNS servers are just caching or relaying — only the authoritative server truly "owns" the answer.

Layer 4: dig google.com — The Full Resolution

Now the full picture. Run:

dig google.com

Output:

;; QUESTION SECTION:
;google.com.        IN  A

;; ANSWER SECTION:
google.com.   300   IN  A  142.250.185.46

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Feb 15 10:23:44 IST 2026
;; MSG SIZE  rcvd: 55

There it is. google.com resolves to 142.250.185.46. That's the IP address your browser will use to make an HTTP connection.

Let's break down the output fields:

QUESTION SECTION: What you asked — the A record for google.com.

ANSWER SECTION: The response — the IPv4 address.

300: TTL of 300 seconds (5 minutes). After 5 minutes, this cached answer expires and needs a fresh lookup.

SERVER: 192.168.1.1: This is your local recursive resolver — usually your router or ISP's DNS server. You didn't query the root servers directly. Your recursive resolver did all the legwork.

That last point is crucial to understand.

The Recursive Resolver: The One Doing All the Work

When you run dig google.com, your query goes to a recursive resolver — typically your ISP's DNS server or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.

The recursive resolver walks the hierarchy on your behalf:

1. Queries a root nameserver: "Who handles .com?" → "Try a.gtld-servers.net."

2. Queries the .com TLD server: "Who handles google.com?" → "Try ns1.google.com."

3. Queries Google's authoritative nameserver: "What's the A record for google.com?" → "142.250.185.46."

4. Returns the answer to you and caches it.

Your browser sent one query. The resolver made three or four separate queries to servers across the internet. This entire process typically completes in under 50 milliseconds.

Every subsequent request for google.com within the TTL window (300 seconds here) comes from cache — no hierarchy walk needed.

To trace this manually without caching:

# Step 1: Ask a root server about .com
dig com NS @a.root-servers.net

# Step 2: Ask a .com TLD server about google.com
dig google.com NS @a.gtld-servers.net

# Step 3: Ask Google's authoritative server for the A record
dig google.com A @ns1.google.com

Each command is one hop. This is exactly what your recursive resolver does automatically, every time.

The Caching Layer: Why DNS Changes Take Time

Remember my earlier frustration about DNS changes taking time? Now it makes sense.

Every DNS response includes a TTL. When a recursive resolver caches google.com -> 142.250.185.46 with a TTL of 300 seconds, it serves that cached answer to everyone who asks for the next 5 minutes — without going back to Google's nameservers.

If you change your A record from one IP to another, every cached copy of the old record across thousands of recursive resolvers worldwide has to expire first. Some resolvers cache aggressively. Some ISPs ignore TTLs entirely and cache for longer. This is why DNS propagation can take anywhere from a few minutes to 48 hours depending on your previous TTL setting.

Developer pro tip: If you know you're about to make a DNS change, lower your TTL to 300 seconds (5 minutes) a day before. Then make the change. Propagation will be much faster because resolvers cached your records with a short TTL. After the change stabilizes, raise it back to something like 86400 (24 hours) to reduce DNS lookup overhead.

Connecting This to Real Browser Requests

When you type google.com and hit enter, your browser doesn't immediately call a DNS server. It checks its own cache first — browsers maintain their own DNS cache. On Chrome: chrome://net-internals/#dns.

If the browser cache misses, it asks the OS. Your OS has its own DNS cache too (resolvectl statistics on Linux). If that misses, the query goes to the recursive resolver configured on your network (/etc/resolv.conf on Linux).

Only if all caches miss does the full recursive resolution happen:

Browser cache
  -> OS cache
    -> Recursive resolver cache
      -> Root -> TLD -> Authoritative
        -> IP address returned

Most requests never make it past the third step. DNS is fast because caching is aggressive at every layer.

What dig Teaches You That Documentation Doesn't

Running these four commands in order genuinely changed how I understood the internet. Not from reading — from seeing the actual responses:

dig . NS              # Root servers: 13 addresses, each a global cluster
dig com NS            # TLD servers: Verisign manages .com
dig google.com NS     # Authoritative: Google manages google.com itself
dig google.com        # Final answer: IP address with TTL

Each command revealed one layer. Together they showed me the complete hierarchy.

For any domain you're working with, swap out google.com for your own domain and run the same sequence. You'll see which nameservers are authoritative for your domain, what TTLs you've configured, which IP your A record points to, and whether your DNS changes have actually propagated to the authoritative layer.

And the next time a deployment breaks because of DNS, you'll know exactly where to look.

DNS resolution is one of those foundational internet concepts that software engineers encounter constantly — domain setup, CDN configuration, service discovery, Kubernetes DNS — but rarely fully understand. The dig command is your lens into all of it. Use it.

I said "the internet." He smiled and said, "Yes, but how?"

I had no answer. I'd been writing code for two years, deploying things, using APIs — and I had zero idea what physically happened between someone clicking a button and my server receiving that request. I just assumed the internet was magic.

It's not magic. There's actual hardware involved, specific devices with specific jobs, and understanding them changed how I think about systems entirely. Whether you're a software engineer, a CS student, or someone who just wants to understand what all those blinking boxes in the IT room actually do — this one's for you.

The Big Picture First

Before getting into individual devices, let me give you the 30-second overview.

Think about a factory. Raw materials come in through a gate. They pass through security checks. Workers route materials to the right departments. Supervisors make sure no single department gets overwhelmed. Finished products leave through the same gate.

A network works similarly. Internet data comes in through one device, gets checked, gets directed, gets distributed to the right machines, and responses go back out the same way. Each device in that chain has one primary responsibility. That separation of responsibilities is what makes networks reliable.

Let's meet each device.

The Modem: Your Gateway to the Internet

Modem stands for Modulator-Demodulator. But forget the acronym. Here's what it actually does.

Your internet service provider (Jio, Airtel, ACT — whoever sends you that monthly bill) delivers internet to your building through a physical cable, fiber line, or telephone wire. The signal traveling through that wire isn't something your laptop or router understands directly. It needs translation.

That's the modem's job. It translates signals from your ISP into a format your local network can use, and vice versa. It's the interpreter at the border.

Think of it like this: your ISP speaks French, your home network speaks English. The modem is the translator sitting at the border checkpoint, converting every message in both directions.

The modem gives you one IP address — the public IP your ISP assigns to you. Everything on your network shares this one public IP when talking to the outside world.

One important distinction: the modem only connects your network to the internet. It doesn't distribute that connection to multiple devices. That's the next device's job.

The Router: The Traffic Director

Here's where most people get confused. Modems and routers look similar, they often come in the same box from ISPs, but they do completely different things.

The router's job is traffic direction — routing data packets to the right device within your network.

Imagine you live in an apartment building. All packages come to the building's front desk (the modem). But who delivers Package A to Flat 3B and Package B to Flat 7A? That's the router. It's the front desk manager who knows where everything needs to go.

When you have multiple devices — your phone, your laptop, your smart TV — they all connect to the router. The router assigns each device a private IP address (like 192.168.1.101, 192.168.1.102) and keeps a routing table tracking which device is which.

When a packet arrives from the internet destined for your laptop, the router checks its table: "192.168.1.102 — that's the laptop. Send it there." When your laptop makes a request, the router notes it, sends it out through the modem, and when the response arrives, delivers it back to the right device.

This translation between your private local IPs and the single public IP from your ISP is called NAT — Network Address Translation. Your router does this constantly, for every device, for every request.

This is also why when you're setting up a backend service and need to accept external traffic, you configure port forwarding on the router. You're literally telling it: "When traffic arrives on port 3000, send it to this specific device."

Switch vs Hub: How Local Networks Actually Work

Once you're inside a network — say, an office with 50 computers — you need a way to connect all those devices. That's where switches and hubs come in. And this distinction actually matters for performance.

The Hub: The Loud Broadcaster

A hub is the old, dumb way to connect devices. When Device A sends data to Device B through a hub, the hub does something baffling: it sends that data to every single device connected to it.

Every device receives the packet, checks if it's addressed to them, and discards it if it isn't. Device B gets the message. Devices C, D, E, F get noisy junk they have to throw away.

This is terrible for performance. As more devices connect, more unnecessary traffic floods the network. It's like a teacher who answers every student's question by announcing the answer to the entire school over the PA system, even when only one student asked.

Hubs are mostly obsolete now, but you'll still see them mentioned in networking courses.

The Switch: The Smart Messenger

A switch does the same job — connecting multiple devices on a local network — but it does it intelligently.

When Device A sends data to Device B, the switch reads the MAC address (a unique hardware identifier for each device's network card) and delivers the data only to Device B. No broadcasting. No noise. Just direct delivery.

The switch learns over time. The first time a device sends something, the switch notes its MAC address and which port it's connected to. After that, it knows exactly where to deliver future packets.

Think of a hub as a postal worker who makes photocopies of every letter and delivers them to every house on the street. A switch is a postal worker who actually reads the address and delivers to the correct house only.

In modern offices and data centers, everything uses switches. Hubs are genuinely antique at this point.

Quick separation: Router connects different networks (your home to the internet). Switch connects devices within the same network (all the computers in your office).

The Firewall: The Security Checkpoint

Every network needs a gatekeeper that decides what traffic is allowed in and what gets blocked. That's a firewall.

Think of it as the security guard at the entrance to a building. They check every person (packet) coming in, compare them against a list of rules, and decide: pass or block.

Firewalls work based on rules you define. Common rules:

• Block all incoming traffic on port 22 (SSH) except from specific IPs

• Allow all outgoing traffic

• Block traffic from known malicious IP ranges

• Only allow HTTP (port 80) and HTTPS (port 443) from outside

When I first deployed a backend application on a cloud VM, I couldn't access it from my browser even though the server was running. Turns out the cloud provider's firewall was blocking port 3000. I hadn't opened that port in the security group rules.

Security groups in AWS, firewall rules in GCP, network security groups in Azure — these are all software-defined firewalls. Same concept, different interfaces.

Hardware firewalls sit physically between your router and internal network in enterprise setups. Software firewalls run on individual machines (like Windows Defender's firewall or ufw on Ubuntu). Both do the same job: enforce rules about what traffic is permitted.

A firewall doesn't just check source and destination IPs. Sophisticated firewalls do deep packet inspection — actually examining the content of traffic to detect malware, unauthorized data exfiltration, or attack patterns.

For any application you deploy publicly, firewall configuration isn't optional. It's the first line of defence.

The Load Balancer: The Traffic Distributor

Here's where we get into territory that's directly relevant to backend engineering and production systems.

Imagine your API server handles 1000 requests per minute comfortably. But you launch a feature that goes viral and suddenly you're getting 10,000 requests per minute. One server can't handle that. So you spin up five servers.

But how do users know which server to talk to? You can't give them five different IP addresses. You need something that sits in front of all five servers, receives all incoming traffic, and distributes it across them.

That's a load balancer.

It's like a receptionist at a busy company. You call the main number (the load balancer's IP). The receptionist doesn't handle your request — they transfer you to the first available representative (server). You never know which representative you got. From your perspective, you just called the company.

Load balancers use different algorithms to distribute traffic:

Round Robin: Request 1 goes to Server A, Request 2 to Server B, Request 3 to Server C, Request 4 back to Server A. Simple rotation.

Least Connections: Send each new request to whichever server currently has the fewest active connections. Smart when requests have varying processing times.

IP Hash: Same client IP always goes to the same server. Useful when you need session persistence — the user stays connected to the same backend throughout their session.

Load balancers also do health checks. Every few seconds, they ping each server: "Are you alive?" If a server stops responding, the load balancer stops sending traffic to it and routes everything to the healthy servers. No manual intervention needed.

This is why Nginx and HAProxy are so common in production setups. They're software load balancers handling traffic distribution at scale. AWS ALB (Application Load Balancer), GCP's Cloud Load Balancing — same idea, managed by the cloud provider.

How They All Work Together

Let me walk you through what happens when a user opens your web application. Every step involves one of these devices.

User types your-app.com and hits Enter.

1. Their DNS lookup resolves your domain to a public IP. That IP belongs to your load balancer.

2. The request travels across the internet and arrives at your modem — the entry point into your infrastructure's network.

3. The router receives the packet from the modem and directs it internally toward the load balancer based on its routing table.

4. The firewall inspects the packet. Is it coming from a blocked IP? Is it hitting an allowed port? Is it a valid HTTP request? Rules pass. Traffic gets through.

5. The load balancer receives the request. Checks which backend server is least busy. Forwards the request to Server 2 of your backend cluster.

6. The switch in your data center or rack handles the physical delivery of that packet from the load balancer to Server 2 — finding the right machine by MAC address.

7. Server 2 processes the request, queries the database, builds a response, and sends it back up the same chain.

8. The response goes back through the switch, through the load balancer, through the firewall (outbound rules check), through the router, through the modem, and out to the user.

All of that happens in milliseconds.

Why Software Engineers Should Care About Hardware

I get it. You write code. You don't configure Cisco switches. But here's the thing — understanding this stack makes you a better engineer, not just someone who can answer networking questions in interviews.

When your API is slow, you'll know whether to look at application code, check if the load balancer is misconfigured, or verify that firewall rules aren't throttling traffic. When a production deployment goes wrong and traffic isn't reaching your new servers, you'll know to check if the load balancer's health checks are passing before you start digging through application logs.

When a security incident happens, you'll understand what the firewall logs are telling you.

These aren't abstract concepts. Every production backend system runs on top of this stack. Cloud providers abstract most of it behind managed services and dashboards, but the same devices, the same responsibilities, the same traffic flow — it's all still there.

Understanding the hardware helps you reason about the system as a whole. And the engineers who can do that — who see beyond just their service to the full stack — are the ones who build systems that actually hold up under real-world conditions.

This is part of my ongoing series on how the internet and backend systems actually work at a foundational level. If you're a developer who wants to go beyond "it just works" to actually understanding the infrastructure underneath your code, this series is for you.

I stared at my screen for an hour. Domain: mine. Website: ready. Why wasn't it showing up?

I hadn't set up DNS records. Didn't even know what they were. Thought buying a domain and having a website was enough. It's not.

Let me save you that confusion.

The Simple Question: How Does a Browser Find Your Website?

Think about this: you type "google.com" into your browser and hit enter. Within milliseconds, you're looking at Google's homepage. But here's the thing – computers don't understand "google.com". They work with IP addresses like 142.250.185.46.

So how does your browser translate "google.com" into that number?

That's where DNS comes in. DNS stands for Domain Name System, but forget the technical term. Think of it as the internet's phonebook.

You know how you save contacts in your phone? Instead of remembering that your friend's number is +91-9876543210, you just save it as "Priyanshu" and tap to call. DNS does the same thing for websites. It translates human-friendly names like "google.com" into computer-friendly numbers like 142.250.185.46.

Without DNS, you'd have to memorize IP addresses for every website you visit. Imagine typing 172.217.160.142 every time you wanted to check Facebook. Nobody's doing that.

Why DNS Records Exist

Here's where it gets interesting. DNS isn't just "domain name = IP address". It's more complex because the internet needs more information than just where your website lives.

Think about a business. You don't just need their address. You might also need:

• Who owns the building (NS records)

• The street address (A records)

• Alternative addresses (AAAA records)

• Nicknames for the location (CNAME records)

• Where to send mail (MX records)

• Additional business info (TXT records)

DNS records are different types of information about your domain, stored in a system that the whole internet can access. Each record type serves a specific purpose.

When I finally understood this, everything clicked. Let me break down each record type.

NS Records: Who's In Charge?

NS stands for Name Server. This tells the internet: "Who manages this domain's DNS records?"

Think of it like property ownership. NS record points to who manages the property, not where it is.

When you buy a domain, registrars set their name servers:

ns1.godaddy.com
ns2.godaddy.com

When I moved to Cloudflare, I changed NS records to:

brad.ns.cloudflare.com
elsa.ns.cloudflare.com

Now Cloudflare manages all my DNS. The NS record says, "For questions about myportfolio.tech, ask Cloudflare."

Most beginners don't touch NS records unless changing DNS providers.

A Records: The Main Address

This is the big one. The A record (Address record) maps your domain name to an IPv4 address.

When someone types "myportfolio.tech" into their browser, the A record says: "That website lives at 192.0.2.1" (example IP).

It's literally that simple:

myportfolio.tech  ->  192.0.2.1

You can also create subdomain A records:

blog.myportfolio.tech  ->  198.51.100.5
api.myportfolio.tech   ->  203.0.113.10

Each subdomain can point to a different server. My main site might be on one server, my blog on another, my API on a third. A records make this possible.

The "A" stands for "Address", but specifically IPv4 addresses (the familiar 4-number format like 192.168.1.1).

AAAA Records: The Future Address

AAAA records do the same as A records, but for IPv6 addresses.

IPv6 looks like: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Longer, uglier, but necessary because we're running out of IPv4 addresses.

Most websites have both:

myportfolio.tech  ->  192.0.2.1      (A - IPv4)
myportfolio.tech  ->  2001:db8::1    (AAAA - IPv6)

Devices use whichever format they support. Modern devices prefer IPv6, fall back to IPv4.

When I started, I only set up A records. Hosting providers usually handle AAAA automatically. Unless managing your own servers, you might not need to configure these manually.

CNAME Records: The Alias

CNAME stands for Canonical Name. It's an alias - one name pointing to another name.

Here's a real scenario I faced: I had my website hosted on GitHub Pages. GitHub told me to point my domain to username.github.io. But I wanted people to access it via www.myportfolio.tech.

I couldn't create an A record because GitHub Pages doesn't give you a fixed IP address. The IP might change. So I used a CNAME:

www.myportfolio.tech  ->  username.github.io

Now when someone visits www.myportfolio.tech, DNS says "that's actually an alias for username.github.io" and looks up that address instead.

Here's the key difference between A and CNAME:

• A record: Points directly to an IP address

• CNAME: Points to another domain name, which then resolves to an IP

Think of it like this: An A record is a street address. A CNAME is "same address as John's place" - you need to look up John's address to find it.

Important rule: You can't use CNAME for your root domain (myportfolio.tech). Only subdomains (www.myportfolio.tech, blog.myportfolio.tech). This confused me for days when I was starting out.

MX Records: How Email Finds You

MX stands for Mail Exchange. These tell the internet where to send emails for your domain.

When someone emails contact@myportfolio.tech, their email server checks your MX records.

myportfolio.tech  MX  10  mail.google.com

The number (10) is priority. Lower = higher priority. Multiple mail servers? Email tries the lowest number first.

I use Google Workspace, so my MX records point to Google:

myportfolio.tech  MX  1   aspmx.l.google.com
myportfolio.tech  MX  5   alt1.aspmx.l.google.com

If the first server is down, email tries the second.

Important: MX records are only for email. Your website can be down and email still works (and vice versa).

TXT Records: The Information Board

TXT records store text information. Like a bulletin board for notes that other services can read.

Common uses:

Domain verification: Proving you own the domain:

myportfolio.tech  TXT  "google-site-verification=abc123"

Email security (SPF): Which servers can send email from your domain:

myportfolio.tech  TXT  "v=spf1 include:_spf.google.com ~all"

Prevents spammers from forging emails from your domain.

DKIM and DMARC: More email authentication, stored as TXT records.

You won't create many TXT records yourself. Services like Google or Cloudflare give you exact TXT records to add.

How It All Works Together

Let's see how these records work for priyanshumaitra.dev:

Website visit:

1. Browser asks: "Where is myportfolio.tech?"

2. DNS checks NS: "Cloudflare manages this."

3. Asks Cloudflare: "What's the A record?"

4. Cloudflare: "192.0.2.1"

5. Browser connects and loads website.

Email:

1. Email server: "Where does mail for myportfolio.tech go?"

2. DNS checks MX: "Send to mail.google.com"

3. Email delivered to Google's servers.

Google checks TXT records for SPF, DKIM verification.

Subdomain:

1. Visit blog.priyanshumaitra.dev

2. DNS finds A record at 198.51.100.5 (different server)

3. Or finds CNAME pointing to hashnode.com/@priyanshumaitra

All records work simultaneously, independently, serving different purposes.

Common Confusions I Had (And You Might Too)

"Can I use both A and CNAME for the same domain?" No. Just pick one. Either point directly to an IP (A record) or point to another domain (CNAME). Not both.

"What's the difference between NS and MX?" NS says who manages ALL your DNS records. MX says where EMAIL goes. Completely different jobs.

"Do I need AAAA records?" Not mandatory, but recommended. Your host probably sets them up automatically.

"Why can't I CNAME my root domain?" Technical reasons involving DNS specifications. Use A records for root domains, CNAME for subdomains.

"How long do DNS changes take?" Usually minutes, sometimes hours. It's called DNS propagation. Different servers update at different speeds.

What I Wish I Knew Earlier

When I bought my first domain, I thought: Buy domain → Point to website → Done.

Reality:

1. Buy domain

2. Set NS records (usually automatic)

3. Set A record to server IP

4. Set MX records for email

5. Add TXT records for verification

6. Maybe CNAME for www subdomain

7. Wait for DNS propagation

8. Troubleshoot

9. Fix the typo in your IP

10. Wait again

Understanding DNS records saves massive time. Now when something breaks, I check DNS first.

The Bigger Picture

DNS records might seem technical and boring, but they're the foundation of how the internet works. Every website you visit, every email you send, every API you call - DNS is working behind the scenes.

You don't need to be a DNS expert to build websites. Most hosting providers handle the basics automatically. But understanding these records helps you:

• Set up custom domains confidently

• Troubleshoot when things break

• Migrate between hosting providers

• Configure custom email addresses

• Understand why changes take time to propagate

That first domain I bought? Once I learned about DNS records, I had it working in 20 minutes. The knowledge has saved me countless hours since.

So next time you type a URL and hit enter, remember: there's a whole system of records working together to get you where you need to go. And now you know how it works.

DNS is one of those things that seems complicated until it clicks. Then it's just addresses, aliases, and instructions. If you're setting up your first domain, take it slow, one record at a time. You'll get it.