Phase 0 Understand how websites work
Before writing code, understand these concepts.
Learn:
What is a website?
Browser vs server
Frontend vs backend
Database
HTTP
Request
Response
URL
Domain
IP address
HTTP vs HTTPS
GET vs POST
Client-server architecture
You should be able to understand:
You
↓
Chrome
↓
Internet
↓
Server
↓
Application
↓
Database
↓
Server
↓
Chrome
↓
You
Practice
Open browser DevTools → Network tab.
Visit a website and observe:
Request
Response
Status Code
Method
URL
Headers
Response
Don't worry about understanding everything yet.
Phase 0 — How Websites Work
[!NOTE]
You don't need to memorize any of this. Read it, understand the big picture, and come back as a reference. Everything will become clearer once you start writing code.
1. What is a Website?
A website is a collection of files (text, images, code) stored on a computer somewhere in the world. When you "visit" a website, your browser downloads those files and displays them on your screen.
Think of it like a restaurant:
| Restaurant | Website |
|---|---|
| You (the customer) | You (the user) |
| The menu you see | The webpage you see (HTML, CSS) |
| The kitchen | The server |
| The recipe book | The application code |
| The pantry/fridge | The database |
| The waiter | HTTP (the protocol carrying requests & responses) |
Key takeaway: A website isn't a single magical thing — it's files on someone else's computer, delivered to your computer over the internet.
2. Browser vs Server
Browser (Client)
The browser is the app on your device — Chrome, Firefox, Edge, Safari. Its job is to:
- Send requests — "Hey, give me google.com"
- Receive files — HTML, CSS, JavaScript, images
- Render (display) those files as a visual webpage
The browser is also called the client — the one asking for something.
Server
A server is a computer (usually in a data center) that is always on and always connected to the internet, waiting to respond to requests.
Its job is to:
- Listen for incoming requests
- Process the request (look up data, run logic)
- Send back a response (usually an HTML page, JSON data, or files)
Real-world analogy:
- Browser = You calling a pizza shop on the phone
- Server = The pizza shop answering the phone, making your pizza, and delivering it
[!TIP]
Your own laptop can act as a server! When you learn backend development, you'll run a "local server" on your machine. It's just a program that listens and responds.
3. Frontend vs Backend
Frontend (Client-Side)
Everything the user sees and interacts with in the browser:
- The layout of the page (HTML)
- The colors, fonts, spacing (CSS)
- Buttons that do things, animations, pop-ups (JavaScript)
Technologies: HTML, CSS, JavaScript, React, Angular, Vue
Analogy: The dining area of a restaurant — what customers see.
Backend (Server-Side)
Everything that happens behind the scenes on the server:
- Processing login credentials
- Fetching your order history from a database
- Sending emails
- Payment processing
Technologies: Node.js, Python (Django/Flask), Java, Go, PHP, Ruby
Analogy: The kitchen of a restaurant — customers can't see it, but that's where the real work happens.
How They Connect
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ FRONTEND │ ────► │ BACKEND │ ────► │ DATABASE │
│ (Browser) │ ◄──── │ (Server) │ ◄──── │ (Storage) │
│ │ │ │ │ │
│ HTML/CSS/JS │ │ Node/Python │ │ MySQL/Mongo │
│ What you SEE │ │ Logic/Rules │ │ Where data │
│ │ │ │ │ LIVES │
└──────────────┘ └──────────────┘ └──────────────┘
4. Database
A database is organized storage for data. Think of it as a super-powered Excel spreadsheet.
When you sign up on Instagram:
- Your username, email, password → stored in a database
- Your posts, likes, followers → stored in a database
- When you log in → the server reads from the database to check your password
Types of Databases
| Type | Examples | Data looks like... |
|---|---|---|
| Relational (SQL) | MySQL, PostgreSQL | Tables with rows & columns (like Excel) |
| Non-Relational (NoSQL) | MongoDB, Firebase | Flexible documents (like JSON files) |
Example — A "users" table in SQL:
| id | username | password_hash | |
|---|---|---|---|
| 1 | yash123 | yash@email.com | a1b2c3... |
| 2 | priya456 | priya@email.com | d4e5f6... |
[!NOTE]
You don't need to learn databases right now. Just understand: data has to live somewhere, and that somewhere is the database.
5. HTTP — The Language of the Web
HTTP = Hyper Text Transfer Protocol
It's the set of rules that browsers and servers use to talk to each other. Think of it as the language the waiter speaks.
Every time you visit a website, your browser speaks HTTP to the server.
6. Request
A request is what your browser sends to the server when you want something.
When you type https://www.google.com and hit Enter, your browser sends an HTTP request that looks roughly like this:
GET / HTTP/1.1
Host: www.google.com
User-Agent: Chrome/120
Accept: text/html
Breaking it down:
| Part | Meaning |
|---|---|
GET |
The method — "I want to GET (read) something" |
/ |
The path — "Give me the homepage" |
HTTP/1.1 |
The version of HTTP |
Host: www.google.com |
Which server to talk to |
User-Agent: Chrome/120 |
"I'm using Chrome" |
Accept: text/html |
"I want HTML back" |
7. Response
A response is what the server sends back to your browser.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 14523
<!DOCTYPE html>
<html>
<head><title>Google</title></head>
<body>... the Google homepage ...</body>
</html>
Breaking it down:
| Part | Meaning |
|---|---|
200 OK |
Status code — "Everything went well, here's your page" |
Content-Type: text/html |
"I'm sending you an HTML file" |
<html>... |
The actual content (the webpage) |
Common Status Codes
| Code | Meaning | When you see it |
|---|---|---|
| 200 | ✅ OK | Page loaded successfully |
| 301 | ↪️ Moved Permanently | Website redirected you |
| 404 | ❌ Not Found | Page doesn't exist |
| 500 | 💥 Internal Server Error | Server crashed or has a bug |
| 403 | 🚫 Forbidden | You don't have permission |
8. URL — The Address of a Webpage
URL = Uniform Resource Locator — it's the address that tells the browser exactly where to go.
https://www.example.com:443/products/shoes?color=red&size=10#reviews
│ │ │ │ │ │
│ │ │ │ │ └─ Fragment (scroll to this section)
│ │ │ │ └─ Query params (filters/search)
│ │ │ └─ Path (which page)
│ │ └─ Port (which door on the server)
│ └─ Domain (which server)
└─ Protocol (how to communicate)
| Part | Example | Purpose |
|---|---|---|
| Protocol | https:// |
How to talk (securely) |
| Domain | www.example.com |
Which server to contact |
| Port | :443 |
Which "door" (usually hidden) |
| Path | /products/shoes |
Which specific page |
| Query | ?color=red&size=10 |
Extra info / filters |
| Fragment | #reviews |
Scroll to a section on the page |
9. Domain & IP Address
IP Address
Every computer on the internet has a unique IP address — a number like 142.250.190.46. This is the real address of a server.
Domain Name
Since nobody wants to remember 142.250.190.46, we use domain names like google.com as human-friendly aliases.
DNS — The Phonebook of the Internet
DNS (Domain Name System) translates domain names to IP addresses:
You type: google.com
↓
DNS lookup: "google.com → 142.250.190.46"
↓
Browser connects to: 142.250.190.46
Analogy:
- IP address = A house's GPS coordinates (27.1751, 78.0421)
- Domain name = The house's street address ("Taj Mahal, Agra")
- DNS = Google Maps converting the address to coordinates
10. HTTP vs HTTPS
| HTTP | HTTPS | |
|---|---|---|
| Full form | HyperText Transfer Protocol | HyperText Transfer Protocol Secure |
| Encryption | ❌ None — data sent as plain text | ✅ Encrypted with SSL/TLS |
| Security | Anyone on the network can read your data | Data is scrambled, unreadable to snoopers |
| Port | 80 | 443 |
| URL | http://... |
https://... |
| Use today | Almost never (browsers warn you) | Everywhere — the standard |
Why it matters:
If you log into a website over HTTP, someone on the same Wi-Fi can literally read your password. With HTTPS, everything is encrypted.
[!CAUTION]
Never enter passwords or credit cards on a site that showshttp://(no 's'). Modern browsers show a "Not Secure" warning for these sites.
11. GET vs POST
These are the two most common HTTP methods — they tell the server what kind of action you want.
GET — "Give me something"
- Purpose: Read / retrieve data
- When it happens: Loading a page, searching, clicking a link
-
Data location: In the URL (visible) →
?q=cats&page=2 - Safe to repeat? Yes — nothing changes on the server
Examples:
- Visiting
google.com→ GET - Searching
google.com/search?q=cats→ GET - Loading your Twitter feed → GET
POST — "Here, take this data"
- Purpose: Send / submit data to the server
- When it happens: Submitting a form, logging in, uploading a file
- Data location: In the request body (hidden from URL)
- Safe to repeat? No — might create duplicates (e.g., double purchase)
Examples:
- Submitting a signup form → POST
- Posting a tweet → POST
- Uploading a photo → POST
Comparison Table
| GET | POST | |
|---|---|---|
| Purpose | Read data | Send/create data |
| Data in URL? | ✅ Yes (visible) | ❌ No (in body) |
| Cacheable? | ✅ Yes | ❌ No |
| Bookmarkable? | ✅ Yes | ❌ No |
| Can be repeated safely? | ✅ Yes | ❌ No |
| Example | Loading a page | Submitting a form |
[!TIP]
There are other methods too — PUT (update), DELETE (remove), PATCH (partial update). You'll learn these when building APIs. For now, just know GET and POST.
12. Client-Server Architecture
This is the fundamental pattern of how the web works:
┌─────────┐ ┌─────────┐
│ CLIENT │ ──── Request ──────────► │ SERVER │
│(Browser)│ ◄─── Response ──────────── │ │
└─────────┘ └─────────┘
- The client (your browser) initiates communication by sending a request
- The server processes the request and sends back a response
- The server never contacts you first (in basic HTTP) — it only responds
This is like a restaurant:
- You (client) call the waiter and place an order (request)
- The kitchen (server) prepares the food and the waiter brings it back (response)
- The kitchen never randomly walks up to your table with food you didn't order
13. The Full Journey — Step by Step
This is the flow you need to understand. Let's trace what happens when you open Instagram:
YOU "I want to see Instagram"
↓
CHROME (Browser) Types instagram.com, hits Enter
↓
DNS Converts "instagram.com" → 157.240.1.174
↓
INTERNET Your request travels through cables/wifi
↓
SERVER Instagram's server receives your request
↓
APPLICATION Instagram's code runs:
"This user is logged in, fetch their feed"
↓
DATABASE Queries: "Get latest 20 posts from
people this user follows"
↓
APPLICATION Formats the data into an HTML page / JSON
↓
SERVER Sends the response back
↓
INTERNET Response travels back through cables/wifi
↓
CHROME (Browser) Receives HTML/CSS/JS, renders the page
↓
YOU See your Instagram feed! 🎉
Timing
This entire journey happens in ~200-500 milliseconds (less than half a second). That's how fast the internet is.
14. 🧪 Practice Exercise — Using Browser DevTools
This is your first hands-on practice. No coding needed — just observation.
Step 1: Open DevTools
- Open Chrome (or any browser)
- Press
F12orCtrl + Shift + I(Windows) /Cmd + Option + I(Mac) - Click the "Network" tab at the top
Step 2: Visit a Website
- Make sure the Network tab is open and recording (there should be a red circle ● at the top-left)
- Type
https://httpbin.org/getin the address bar and hit Enter - You'll see lines appear in the Network tab — each line is one request
Step 3: Observe the First Request
Click on the first item in the list (usually named get).
You'll see panels showing:
✅ What to look for:
| What | Where to find it | Example value |
|---|---|---|
| URL | In the "Headers" section → Request URL | https://httpbin.org/get |
| Method | In the "Headers" section | GET |
| Status Code | In the "Headers" section | 200 OK |
| Response Headers | In the "Headers" section → Response Headers | Content-Type: application/json |
| Response Body | Click the "Response" or "Preview" tab | JSON data |
Step 4: Try a POST Request
- Open a new tab
- Open DevTools (F12) → Network tab
- Paste this into the address bar:
https://httpbin.org/post - You'll get an error (because browsers send GET by default) — that's expected!
- This tells you: the server only accepts POST at this URL, but your browser sent GET
Step 5: Observe Multiple Requests
- Go to
https://www.google.comwith DevTools Network tab open - Notice there are dozens of requests — not just one!
- Each image, CSS file, JavaScript file, and font is a separate request
[!IMPORTANT]
A single webpage often makes 30-100+ HTTP requests to load completely. The HTML is just the skeleton — it then triggers requests for all the images, styles, and scripts.
Step 6: Status Codes in Action
Try visiting these URLs and check the status code in DevTools:
-
https://httpbin.org/status/200→ Should show 200 (OK) -
https://httpbin.org/status/404→ Should show 404 (Not Found) -
https://httpbin.org/status/500→ Should show 500 (Server Error)
15. Summary Cheat Sheet
| Concept | One-Line Summary |
|---|---|
| Website | Files on a server, displayed by your browser |
| Browser | The app that requests and displays web pages |
| Server | A computer that listens for and responds to requests |
| Frontend | What the user sees (HTML, CSS, JS) |
| Backend | Logic that runs on the server (Node, Python, etc.) |
| Database | Where data is stored (like a smart spreadsheet) |
| HTTP | The rules/language browsers and servers speak |
| Request | What the browser sends ("give me this page") |
| Response | What the server sends back (the page + status) |
| URL | The address of a webpage |
| Domain | Human-friendly name for a server (google.com) |
| IP Address | The real numeric address of a server |
| HTTPS | HTTP + encryption = secure communication |
| GET | "Read/fetch something" |
| POST | "Send/submit data" |
| Client-Server | Client asks → Server responds. Always. |
✅ Phase 0 Checklist
Before moving to Phase 1, make sure you can answer:
- [ ] What happens when I type a URL and press Enter?
- [ ] What's the difference between frontend and backend?
- [ ] What does a database do?
- [ ] What's a request? What's a response?
- [ ] What's the difference between GET and POST?
- [ ] What does a 404 error mean? What about 500?
- [ ] Why is HTTPS better than HTTP?
- [ ] I've opened DevTools and seen real requests/responses
[!TIP]
You do NOT need to understand everything perfectly. If you can explain the restaurant analogy to someone — you're ready for Phase 1. Understanding deepens as you build things.
Top comments (1)
How the Web Actually Works: What Happens When You Type a URL
Most people learn web development backwards.
They start with HTML.
Then CSS.
Then JavaScript.
Then React.
But they still can't answer one simple question:
What actually happens when I type a URL and press Enter?
Before writing code, understand the system you're writing code for.
Once you understand the big picture, HTML, APIs, databases, servers, and cloud infrastructure stop feeling like separate topics.
They start fitting together.
1. A Website Is Not Magic
When you visit a website, your browser is requesting files and data from computers somewhere on the internet.
Those computers are called servers.
The simplest mental model is a restaurant.
You ask for something.
The system processes your request.
You receive something back.
That's the foundation of the web.
2. Browser vs Server
Your browser is the client.
Chrome, Firefox, Edge, and Safari are all examples.
The browser:
The server is the computer waiting to receive those requests.
It:
Think about ordering pizza.
You = browser
Pizza shop = server
You make the request.
The shop processes it.
The pizza comes back.
3. Frontend vs Backend
This distinction becomes much easier with one question:
Can the user directly see it?
If yes, you're probably looking at the frontend.
If it's happening behind the scenes, you're probably looking at the backend.
Frontend
The frontend is what users see and interact with:
Common technologies include:
Backend
The backend handles the work users don't directly see:
Common technologies include:
The basic architecture looks like this:
The frontend talks to the backend.
The backend talks to the database.
The response travels back.
4. Where Does the Data Live?
A database is organized storage for application data.
Think of it as a much more powerful version of a spreadsheet.
For example, a users table might look like:
There are different types of databases.
Relational databases
Examples:
Data is organized into tables, rows, and columns.
NoSQL databases
Examples:
Data can be represented as flexible documents.
You don't need to master databases yet.
Just remember:
Applications need somewhere to store data.
That's the database.
5. HTTP: How the Web Talks
HTTP stands for:
HyperText Transfer Protocol
It's the set of rules used by clients and servers to communicate.
Your browser sends a request.
The server sends a response.
That's HTTP at its simplest.
6. What Is a Request?
Imagine typing:
and pressing Enter.
Your browser sends a request to the server.
A simplified request could look like:
The important idea isn't memorizing every line.
Understand the structure.
The browser is saying:
"I want this resource, from this server, and here's information about me and what I can accept."
7. What Is a Response?
The server processes the request and sends something back.
For example:
The response contains information about what happened and the content being returned.
One of the most useful pieces of information is the status code.
Some common ones:
These numbers become incredibly useful when troubleshooting applications.
8. A URL Is More Than a Website Name
Consider:
A URL contains multiple pieces:
Once you understand these pieces, URLs stop looking complicated.
They're structured addresses.
9. Domain vs IP Address
Computers communicate using IP addresses.
Humans prefer names.
Instead of remembering something like:
we use:
DNS connects the two.
Think of DNS as the internet's phonebook.
You remember the name.
DNS helps find the address.
10. HTTP vs HTTPS
HTTP sends web communication without the protection provided by TLS encryption.
HTTPS adds encryption.
http://https://That's why modern websites overwhelmingly use HTTPS.
When sensitive information such as passwords or payment details is involved, encrypted communication is essential.
11. GET vs POST
Two HTTP methods you'll encounter constantly are:
GET
and
POST
Think:
GET = Give me something
Used to retrieve data.
Examples:
POST = Here is some data
Used to submit data.
Examples:
The key distinction:
Later you'll encounter:
But GET and POST are a great place to start.
12. The Client-Server Model
Everything we've discussed comes together here.
The client asks.
The server processes.
The database provides data when needed.
The server responds.
The browser renders.
13. What Happens When You Open a Website?
Now let's put everything together.
You type:
and press Enter.
What happens?
The browser needs to find the server.
DNS resolves the domain.
The request travels through the network.
The server receives it.
The application processes it.
The application may query the database.
The server prepares the response.
The response travels back.
The browser receives the resources.
The browser renders the page.
And finally:
You see the website.
A complicated system becomes much easier once you see the sequence.
14. Your First Hands-On Exercise
You don't need to write code yet.
Open Chrome.
Press:
or:
Then open the:
Network tab.
Now visit:
Look at the request.
Find:
You should see something similar to:
Now you're no longer just reading about HTTP.
You're watching it happen.
15. Try Different Status Codes
Open:
Then:
Then:
Watch the Network tab.
You're deliberately creating:
This is the beginning of learning how developers troubleshoot real applications.
16. One Page Does Not Mean One Request
Here's another useful observation.
Open:
with the Network tab open.
You may see many requests.
Why?
Because the page isn't just one file.
The browser may request:
The HTML is only part of the story.
A modern webpage is a collection of resources working together.
The Mental Model to Remember
Don't memorize hundreds of definitions.
Remember this:
And remember:
Browser → Request
Server → Response
Frontend → What you interact with
Backend → What happens behind the scenes
Database → Where application data lives
DNS → Domain → IP
HTTPS → Encrypted communication
GET → Retrieve
POST → Submit
Once this mental model is clear, you're ready to start writing code.
And that's where the next phase begins.