How the Web Works

A web page on your screen is the result of work in two places. Your browser asks for resources, and a server sends responses. Those roles explain both a simple personal site and a page assembled from several services.

Who asks and who answers

A client is a device and program that requests something. Chrome, Edge, Firefox, and Safari are browser clients. A server is a computer running software that accepts requests and sends back stored files or content it produces. Apache and nginx are examples of web server software. The word "server" can name the computer or that software.

In an HTTP exchange, the client sends a request naming what it wants. The server sends a response to that request. Picture ordering food at a counter: the order slip asks for something, and the tray is the reply. The browser initiates the exchange; an ordinary page response answers a request.

Client and server are roles, not fixed types of machine. A laptop can run both your browser and a test server. A site is hosted when a reachable server makes its resources available. A server reached through localhost runs on your own computer; that address does not take another person's browser to your laptop.

A page is a collection of resources

A resource is something an address can identify: a page, stylesheet, script, image, font, video, or piece of data. The first page request usually retrieves HTML. The browser reads that HTML to discover the other resources it needs and requests each separately.

For example, an article names two stylesheets, one script, and five images. Count the HTML too:

• One HTML resource starts the page.
• Two CSS resources supply its styles.
• One JavaScript resource supplies behavior.
• Five image resources supply pictures.

That makes nine resources and, with an empty browser cache, nine HTTP requests for those resources. A cache stores downloaded copies for reuse. Fresh cached files can reduce the requests that travel over the network on another visit.

The resources need not share a server. The HTML might come from www.example.com, pictures from images.example.net, and a video from another service. Each resource's address tells the browser where to ask. A successful HTML request therefore does not establish that every image or script also loaded.

Stored files and generated replies

In both cases, the browser receives resources it can read or display. A generated HTML page is still HTML when it reaches the browser. The browser holds downloaded copies, while the server keeps the site's original files or the program that produces them.

The web runs over the internet

The internet is the worldwide network that carries data between computers. The web is a service using that network: linked resources addressed by URLs and exchanged through HTTP. Email, online games, and video calls also use the internet. The web is one use of the network, not the name for every activity on it.

Pressing Enter on a web address starts several tasks. Each has a different job, so a failure at one stage leaves different evidence from a failure at another.

Read the address and find the server

Take https://www.example.com/news.html. The browser reads https as the scheme, www.example.com as the host, and /news.html as the requested path. Text such as "weather tomorrow" is normally treated as a search and sent to the default search engine instead.

The browser needs an IP address, a numeric network address such as 203.0.113.10 or the IPv6 example 2001:db8::1. DNS, the Domain Name System, finds addresses associated with domain names. The browser and operating system can reuse a recent DNS answer from a cache, so every page visit does not require a new lookup.

Connect and protect the exchange

The browser connects to the server. For HTTPS, it sets up an encrypted connection using TLS. The server presents a certificate that lets the browser check its identity for the requested domain. Encryption protects the messages from being read or changed by others on the network. A secure-connection indicator describes that protection; a scam site can also have a valid certificate.

Data travels across the network in small pieces called packets, through devices called routers, and is put together at the destination. The browser and operating system handle that transport while the browser works with the HTTP messages.

Request, receive, and build

1. The browser sends an HTTP request for /news.html.
2. The server responds with a status code, headers describing the reply, and usually a body containing the HTML.
3. The browser reads the HTML and requests the stylesheets, scripts, images, and other resources it names.
4. It builds the page, applies styles, runs scripts, and draws content on screen.

Several resource requests can overlap. The browser can show text before every image finishes downloading; the page is assembled progressively.

For a small page at https://example.org/, suppose the HTML names only style.css and logo.png, both on the same host. With no relevant cached entries, one host needs a DNS lookup and the three resources need three HTTP requests. On a later visit, a cached DNS answer avoids that lookup. Fresh resource copies can be reused, and older copies can be checked with the server. A 304 Not Modified response means a stored copy is still current and the file body need not be sent again.

Locate a failure by its evidence

A DNS failure has no HTTP status code because no HTTP response arrived. A 404 is different: the server answered. Chrome may show a name error such as DNS_PROBE_FINISHED_NXDOMAIN, but the wording is a browser message, not a server response.

A URL, or Uniform Resource Locator, addresses one resource. The domain name is only one part of that address. The full pattern is scheme://host:port/path?query#fragment, though many addresses leave out optional parts.

Take an address apart

Read this address in pieces:

https://shop.example.com:8443/products/shoes.html?color=blue&size=42#reviews

The punctuation separates parts: : follows the scheme, ? starts the query, and # starts the fragment. The separators are not part of the query or fragment values.

Scheme, host, and port

The scheme selects how the address is handled. http uses unencrypted HTTP; https uses encrypted HTTP. mailto:info@example.com asks an email program to compose a message, while file:/// addresses a local file.

The port selects a service on the host. If omitted, HTTP uses port 80 and HTTPS uses 443. Thus https://example.com/ and https://example.com:443/ identify the same destination and path. Local test servers often use ports 3000, 5500, or 8080; http://localhost:5500/ includes its port because it is not HTTP's default.

The scheme and host ignore letter case. The host www.example.com is a different name from example.com; both reach a site only when its owner has configured them that way.

Path, query, and fragment

On a simple static site, a path follows the server's folders and files. On other sites, server software decides what a path returns, so a path need not name a file on disk. A folder address ending in / often serves a default page such as index.html.

A query string carries input after ?. In /search?q=web+basics&page=2, & separates two fields: the search words and page number. These fields travel to the server as part of the request target.

A fragment stays in the browser. The suffix #reviews usually scrolls to an element with id="reviews". The browser requests the path and query without the fragment. Changing only #top to #reviews does not ask the server for a different file.

Preserve the exact characters

Web paths use forward slashes /. A space can be percent-encoded as %20. Form encoding uses + for a space and %40 for @; an ordinary URL path or query can contain a literal @, so form encoding and general URL spelling are not identical rules.

Paths may be case-sensitive even though hosts are not. /Images/Logo.png can differ from /images/logo.png. Copying the host correctly but changing a path's capital letters can still request the wrong resource.

A domain name gives people a readable name to use in place of a numeric IP address. Its dotted parts also show how the name is organized. Reading those parts correctly matters when two addresses contain similar words.

Start at the right end

Each part between dots is a label. In blog.example.org, the rightmost label, org, is the top-level domain, or TLD. The registered domain is example.org, and blog is a subdomain controlled through that domain.

Generic TLDs include .com, .org, .net, .dev, and .shop. Country-code TLDs have two letters, such as .nl, .de, .jp, .br, and .ca. Some have eligibility rules: .gov is restricted to verified US government organizations. New institutional .edu registrations generally require eligible, institutionally accredited US postsecondary institutions; some organizations qualify under other policies, and older registrations can have exceptions. ICANN coordinates the domain name system's top-level names.

A registered name is not always just the final two labels. Under .co.uk, for example, the registered name in news.example.co.uk is example.co.uk. Read the public ending first, then identify the name registered beneath it.

Familiar words can sit inside someone else's name

Compare these hosts:

In the second host, the words example.com are labels on the left of example.net. They do not give the owner of example.com control of the address. Identify the host before reading it from the right; a familiar name in a path is not the host either.

www is an ordinary subdomain label. A site owner can use it, omit it, or redirect between names. Its presence is not required by the web.

Registration and hosting are separate

A registrar handles domain registrations for customers. A registry maintains the records for a TLD. Registering a domain gives you the right to use that name for a term, usually one or more years. You renew it to retain that right; an expired name can eventually become available to someone else.

The owner then configures DNS records to associate the name with a hosting server's address. The domain is not the website's files. The same name can be pointed to a different server, and one server can serve several domains. Cached DNS answers explain why a changed address can take minutes or hours to be seen everywhere.

Name rules and local names

Ordinary host labels use letters, digits, and hyphens, with no hyphen at either end. Each label can have up to 63 characters, and an ordinary full name can have up to 253 characters. Names ignore letter case. Internationalized domain names support other writing systems; their encoded ASCII labels begin with xn--.

The special name localhost means the computer making the request. Its loopback addresses include 127.0.0.1 and ::1. If a learner opens http://localhost:3000/, the browser looks for a service on that learner's own computer.

A link can contain a full address or instructions for finding a resource from the current page. To predict where it goes, start with the page's address and follow the path one part at a time.

Choose the starting point

An absolute URL identifies its own host and works from any page. It is useful for another website. A relative URL omits the beginning and is completed from the page's address. For files inside a site, this helps the folder move together from a laptop to a server.

Work through a folder tree

Suppose a site contains these files:

my-site/
  index.html
  about.html
  images/logo.png
  styles/main.css
  blog/first-post.html

From index.html, about.html stays in the same folder. images/logo.png enters the images subfolder, and styles/main.css enters styles.

From blog/first-post.html, the starting folder is blog. To reach the logo, use ../images/logo.png: first go up to the site folder, then enter images. The link images/logo.png would instead look inside blog/images, where this tree has no logo. To reach the home page from that post, use ../index.html.

Trace nested addresses

On https://example.com/blog/2026/post.html:

• photo.jpg becomes https://example.com/blog/2026/photo.jpg.
• ../index.html becomes https://example.com/blog/index.html.
• /about.html becomes https://example.com/about.html.
• #comments stays on this document and identifies its comments element.

A leading / replaces the current path from the site root. It does not mean "one folder up." Repeating ../ climbs multiple folder levels: ../../about.html from the nested post goes up through 2026 and blog before finding about.html.

Preview links in the right environment

A root-relative path works with an HTTP server, including a local server. On a file:/// page, / points toward the root of the computer's file system, not your project folder. Use a local server when testing this style of link.

A path such as C:\Users\sam\site\logo.png or file:///Users/sam/site/logo.png identifies a location on one computer. Other visitors do not have that folder. Link with a web path that stays inside the site's structure.

Match names exactly

Use lowercase names, hyphens instead of spaces, and correct extensions: contact-form.html is easier to link reliably than Contact Form.HTML. Windows and macOS commonly ignore filename case, while many web servers distinguish it. A local link to Logo.png can fail online when the actual name is logo.png.

A home page named index.html is a common server default. Requesting a folder such as /blog/ usually serves its index.html when that server is configured with this default.

HTTP, the Hypertext Transfer Protocol, defines how web clients request resources and how servers reply. HTTPS carries those messages over an encrypted connection. Reading a request shows what the browser asked the server to do.

Read the message in order

Here is a request shown in HTTP/1.1 text form:

GET /products/shoes.html?color=blue HTTP/1.1
Host: shop.example.com
Accept: text/html
Accept-Language: en-US,en;q=0.9

The first line contains the method, the request target, and the HTTP version. GET asks to retrieve a resource. The target includes the path and query; it excludes any fragment. The host appears in the Host header, which lets one server distinguish the sites it serves.

A header is a named field such as Accept: text/html that carries information about the request or its content. An empty line ends the headers. Some requests then carry a body, the data being sent. This GET example has no body.

HTTP/2 and HTTP/3 encode messages differently, but retain methods, targets, headers, and bodies. DevTools presents them in readable form, so these message parts remain useful across versions.

Choose a method for the action

Following a normal link or typing an HTTP address makes a GET request. An HTML form uses GET by default and POST when it specifies method="post".

With a GET form, fields go into the URL query. This suits a search whose results you want to bookmark or share. POST places submitted fields in the request body and suits actions such as creating an account or posting a comment.

POST does not encrypt anything by itself. On plain HTTP, both query data and body data can be read in transit. HTTPS protects both. Passwords belong in POST bodies over HTTPS because URLs also appear in browser history and may be stored in logs.

Read a form submission

POST /signup HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 38

name=Ana+Silva&email=ana%40example.com

The target is /signup. Content-Type identifies the body's form encoding. The body contains the name "Ana Silva" and the email "ana@example.com": + decodes to a space and %40 to @. There are 38 bytes here, matching Content-Length.

Reading, repeating, and identifying requests

A safe method is intended to read without changing server state; GET, HEAD, and OPTIONS are safe. An idempotent method has the same intended effect if repeated. Safe methods, PUT, and DELETE are idempotent. POST is not guaranteed to be: repeating a submission can create a second comment or order.

Other request headers include User-Agent for client information, Accept for acceptable formats, and Accept-Language for language preferences. Cookie returns stored cookie values. Referer, with its historical spelling, can identify the referring page; browsers may omit or reduce it according to policy.

The response is the server's answer to one request. Its code tells you the outcome, its headers describe the reply, and its body carries the returned content when a body is allowed.

Separate the parts

A response in HTTP/1.1 text form can begin like this:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1534
Cache-Control: max-age=600

<!DOCTYPE html>
<html lang="en">
...

The status line gives the version, code 200, and human-readable reason phrase OK. Programs use the number. HTTP/2 and HTTP/3 do not carry that reason phrase. After the headers and an empty line, the body begins with the HTML.

Content-Length describes a byte count, not a character count or a visible page size. For an image response with Content-Length: 24576, the body has 24,576 bytes: 24.576 kB, or about 24.6 kB using 1 kB = 1,000 bytes.

Identify the body by its media type

The media type, also called a MIME type, is sent in Content-Type.

The header tells the browser how to handle the body; a filename extension alone is not enough. If a stylesheet URL returns an HTML error page with Content-Type: text/html, the browser rejects it as CSS. This often explains a page with text but no intended styling.

Bodies can be text or binary bytes. A response to HEAD has no body, even when its headers describe the resource a GET would return. 204 No Content and 304 Not Modified also have no body.

Carry identity between separate requests

HTTP is stateless: an exchange does not automatically remember an earlier one. A cookie supplies information that connects requests to an ongoing session.

1. The server responds with Set-Cookie: session=abc123.
2. The browser stores the cookie.
3. On later matching requests, it sends Cookie: session=abc123.
4. The server can use that value to look up the session, such as the learner's login or cart.

Cookie scope and browser rules control which requests receive it.

Reuse content without downloading it again

Cache-Control: max-age=600 lets the browser treat a stored response as fresh for 600 seconds, or 10 minutes. During that period it can reuse the copy without contacting the server. After it becomes stale, the browser can ask whether it changed. A 304 means reuse the cached body; a 200 can deliver a replacement.

If saved CSS changes do not appear, check whether the browser reused a copy. A hard reload, commonly Ctrl+Shift+R on Windows/Linux or Cmd+Shift+R on macOS, or DevTools' Disable cache option helps fetch fresh resources. That checkbox applies while DevTools is open.

Other useful response headers include Location for a redirect destination, Date for the response date, and Server for server software information when supplied.

A status code is the three-digit outcome in an HTTP response. The number describes one request, so one page can have successful HTML, a missing image, and a redirected script at the same time.

Start with the first digit

200 OK is the usual successful GET. 201 Created reports creation of a new resource, often following POST. 204 No Content reports success without a response body.

Follow a redirect without confusing it with a failure

301 Moved Permanently and 308 Permanent Redirect give a permanent new location. 302 Found and 307 Temporary Redirect give a temporary one. The response's Location header identifies the next address.

For example, a request to http://example.com/ can return 301 with Location: https://example.com/. The browser then sends a new request to the HTTPS address, which returns 200. Those are two exchanges, not a single response with two codes.

307 and 308 preserve the method when the browser repeats the request. After 301 or 302, a browser may change POST to GET. 304 Not Modified is a different kind of 3xx result: it validates a cached copy and sends no replacement body.

Match the code to the useful next check

A 503 may include Retry-After to indicate when to retry. The difference between 401 and 403 is especially useful: missing or invalid authentication differs from a refusal of permission. A 4xx label identifies the request side to investigate, but a site can still have a broken link or a configuration problem that causes it.

Diagnose the particular resource

Suppose HTML and CSS return 200, while images/Logo.PNG returns 404. The server's actual file is images/logo.png. Correcting the link's case makes it identify the stored file. A server answered the failed request; the entire site was not unreachable.

For a 5xx response, the failure is in server-side handling. A learner viewing someone else's site can retry later or report it. A developer responsible for that server investigates its code or upstream service.

Read the response, not just the screen

An error message inside HTML does not determine the status. A site can return 200 with a "not found" message, called a soft 404. Conversely, a real 404 can include a polished HTML error page. Use the Network panel to read the actual code.

When DNS or the connection fails, no HTTP response may exist at all. A browser-generated error then has no server status to inspect. An isolated 404 for /favicon.ico, the small tab icon browsers may request, often leaves the page content working.

A page combines content, presentation, and behavior. Recognizing these jobs helps you choose which file to inspect when you want to change something.

HTML describes what the content is

HTML, HyperText Markup Language, gives content structure and meaning: headings, paragraphs, lists, links, images, tables, and forms. It is a markup language. It describes elements instead of performing calculations or running loops.

In <a href="about.html">About us</a>, the opening tag is <a href="about.html">. The href attribute gives the destination. "About us" is the content, and </a> closes the element. Attributes belong inside the opening tag.

Some elements are void and have no content or closing tag. For example, <img src="logo.png" alt="Company logo"> supplies an image address and a text alternative. <br>, <link>, and <meta> are other void elements.

Choose elements for meaning. Use a heading because the text introduces a section; use CSS when you want larger text or extra spacing. Several <br> elements are a poor substitute for spacing rules.

CSS controls how content looks

CSS, Cascading Style Sheets, sets color, type, spacing, layout, and adaptation to different screen widths. Read this rule:

h1 {
  color: navy;
  font-size: 2rem;
}

The selector, h1, identifies the elements to style. Each declaration pairs a property with a value. color: navy; sets the color property to navy. The colon separates property and value; the semicolon ends the declaration.

JavaScript responds to actions

JavaScript is a programming language. It responds to clicks and typing, changes the live page, checks form input, and requests more data without a full page reload. It is a different language from Java.

For a theme button, a script can find the button, listen for clicks, and switch a CSS class:

document.querySelector("button").addEventListener("click", () => {
  document.body.classList.toggle("dark");
});

The script changes whether the body has the class dark; CSS supplies that class's appearance. A static information page can work with HTML and CSS alone.

Connect the files in HTML

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>My first page</title>
    <link rel="stylesheet" href="styles/main.css">
    <script src="scripts/app.js" defer></script>
  </head>
  <body>
    <h1>Hello, web</h1>
    <p>This text is structured by HTML and styled by CSS.</p>
    <button>Switch theme</button>
  </body>
</html>

The <head> holds page information and file links. The <body> contains the displayed content. The browser requests styles/main.css and scripts/app.js separately from the HTML. All three are plain-text files you can open in a code editor.

Separation of concerns keeps content in HTML, appearance in CSS, and behavior in JavaScript. One stylesheet can style many pages. A meaningful heading and an ordinary link still work if styling or scripting fails, while features that depend on JavaScript need their script to work.

The browser does not display HTML as a picture of a text file. It turns the file into objects, works out their styles and positions, and draws the result. JavaScript can then change those objects.

Build a tree from HTML

The DOM, or Document Object Model, is the browser's live tree of elements and text. Consider:

<body><h1>News</h1><p>Hi <a href="/">home</a></p></body>

The body has two element children, h1 and p. The heading contains "News". The paragraph contains the text "Hi " and an a element, which contains "home". The link is inside the paragraph, not directly inside the body.

While reading HTML, the browser discovers resources in elements such as <link>, <script>, and <img>. It requests those resources and reads the CSS to calculate each element's final styles. Layout calculates sizes and positions. Paint draws the pixels. These tasks can happen again when content or styles change.

Let scripts run when their elements exist

A classic external script without defer or async pauses HTML parsing while it downloads and runs. If it is in the head and tries to find a button later in the body, that button has not been built yet. document.querySelector("button") returns null, so calling addEventListener on the result produces an error.

Add defer to let a script download while HTML parsing continues and run once that parsing is complete. Moving a plain script just before </body> also lets earlier elements exist first. async does not guarantee that a later button exists; its download may finish early.

Source HTML and the live DOM can differ

View Page Source shows the delivered HTML. The Elements panel, called Inspector in Firefox, shows the live DOM. JavaScript may have added content, changed text, or removed elements. The browser may also have repaired malformed HTML, for example by closing an element.

If a heading changes after a click, the Elements panel shows the changed text. View source still shows the HTML originally received. A DOM change can trigger updated styles, layout, and paint without fetching a new HTML document.

Different errors have different effects

Browsers repair HTML using defined rules and skip CSS declarations they do not understand. A JavaScript syntax error, such as an unfinished expression, prevents that script file or block from starting. An uncaught runtime error ends the current execution, skipping later lines in that run. Other scripts and already registered event handlers can still work. This explains a page whose content and style remain visible while one feature fails.

Browser engines implement common standards: Blink in Chrome and Edge, Gecko in Firefox, and WebKit in Safari. Small implementation differences make testing in more than one browser useful. Browsers also build an accessibility tree from the page's structure so screen readers can present meaningful elements and relationships.

A web project starts as files in a folder. A code editor helps you write those files, and a browser lets you preview what they produce. Keeping the editor and browser pointed at the same copy of the project prevents many confusing results.

Choose a plain-text code editor

A code editor saves plain-text files and adds syntax highlighting, completion, error hints, a file tree, and other coding aids. Word processors store document formatting and may replace straight quotes with curly quotes, so they are unsuitable for source code.

Visual Studio Code is a free option for Windows, macOS, and Linux. Other editors include Sublime Text, Zed, and WebStorm. An online playground such as CodePen suits short experiments; the file and path skills carry over between tools.

Create and open a project

For a first VS Code project:

1. Download and install the editor from its official website, https://code.visualstudio.com/.
2. Create a folder such as web-projects/my-first-site.
3. Choose File → Open Folder and open my-first-site so the file tree shows the whole project.
4. Create index.html. In HTML mode, type ! and choose the Emmet suggestion for an HTML skeleton.
5. Save with Ctrl+S on Windows/Linux or Cmd+S on macOS.

Use a folder structure that matches the roles of your files:

my-first-site/
  index.html
  styles/main.css
  scripts/app.js
  images/logo.png

Use lowercase names and hyphens, with no spaces. Keep the extensions visible so index.html does not silently become index.html.txt. Save text as UTF-8 and include <meta charset="utf-8"> in the HTML head so text such as accented names is interpreted correctly.

Choose a preview method

A local web server serves a folder on your own computer. It might use http://localhost:5500/ or http://127.0.0.1:3000/; use the address your preview tool supplies. Root-relative paths need a server to start at your site's root. Features such as JavaScript modules or fetching data also need HTTP preview because browsers restrict their use on local-file pages.

In VS Code, Microsoft's Live Preview extension or a Live Server extension can start a server and refresh the preview after saving. Check the publisher before installing extensions because extensions run code on your computer. Format on save, word wrap, and Auto Save can make editing easier; a formatter such as Prettier keeps formatting consistent.

Follow the edit-and-check loop

Edit, save, reload or let the preview reload, inspect the result, and fix the file. If the browser still shows old content, check the editor's unsaved indicator and compare the preview's path with the project you opened. You may have two folders with the same page name. Also check the exact filename and extension; a text-file suffix can stop the browser from treating a file as an HTML page.

Browser developer tools expose the page you are actually running. Use them to test a style, read an error, or compare the live page with the file in your editor.

Open the tools and choose a panel

Right-click part of a desktop page and choose Inspect. Common shortcuts are F12 or Ctrl+Shift+I on Windows/Linux and Cmd+Option+I on macOS. Safari first needs its developer features enabled in Settings → Advanced; the option's wording varies with the Safari version.

Find a style that wins

Inspect a heading. Selecting its node highlights its box on the page, including content, padding, border, and margin. The Styles pane lists rules and their source locations, such as main.css:12. A crossed-out declaration is not taking effect there: another rule may override it, or the declaration may be invalid. Invalid declarations can also carry a warning indicator.

Open Computed to see the final values. If two rules specify different text colors, the computed color tells you the result. You can temporarily change a value, disable a declaration, or edit text and attributes to test an idea.

Ordinary live edits affect your tab's DOM or styles. Reloading replaces them with the loaded files. To keep an improvement, make the same edit in the source file, save, and reload. Changing a displayed price in Elements changes the local display; it does not change the server's stored price.

Read a console error as a clue

An error includes a message and usually a file and line. For example:

Uncaught TypeError: Cannot read properties of null
(reading 'addEventListener') at app.js:3

Read app.js:3 as the source location to inspect. The code tried to use a missing object. If a selector searched for a button, check that its spelling matches an element and that the element existed when the script ran. The message alone does not choose between those causes.

The Console also shows failed resource loads, such as a GET ending in 404, and messages printed by console.log(). A script error can explain a nonworking button even when its file downloaded successfully.

Try a small expression and a narrow screen

The Console can evaluate JavaScript. Typing 2 + 3 returns 5; document.title returns the current title. The assignment document.body.style.background = "lightyellow" changes the page's background in the tab. Do not paste code from someone you do not trust into the Console; it runs with access to the page and can misuse an account.

Use the phone-and-tablet icon for responsive mode. Choose a narrow width such as 375 CSS pixels to see how the layout fits. This simulates a viewport, not every behavior of a real phone; a real-device check adds information that resizing cannot provide.

The Network panel shows the separate exchanges behind a page. It can reveal why one image is missing, why styling failed, or why a reload transferred less data than expected.

Record before reloading

Open DevTools, choose Network, make sure recording is active, and reload the page. The panel cannot reconstruct requests that finished before it was opened. If the list is empty, check recording and filters, then reload again.

Rows show each request's name or URL, method, status, type, size, and time. The waterfall shows when requests started and how their timings overlap. It helps you see a page load as several resource fetches instead of one indivisible action.

Open a row for the full evidence

Select a request. Headers shows the requested URL and method, response status, and request and response headers. Preview displays a useful view of supported response content. Response shows the returned content more directly, while Timing breaks down the time spent in phases of the request.

For a missing image, compare the full requested address with the image's actual location. A filename alone can hide a wrong parent folder.

Diagnose an example load

Five requests transferred 31.8 kB in total. The Hero.jpg request failed. Its small HTML body is the server's error page, which explains the text/html media type on an image request. If the actual file is images/hero.jpg, change src="images/Hero.jpg" to src="images/hero.jpg" and reload to test the fix.

Filter on Img to focus on pictures, CSS for stylesheets, or a name to find a particular resource. When a stylesheet fails, inspect both its status and Content-Type. Even a 200 cannot make an HTML response into usable CSS.

Keep redirects and cached responses visible

Turn on Preserve log, called Persist Logs in Firefox, before following navigation that you want to trace. An HTTP-to-HTTPS redirect can then show a 301 row and its Location header followed by a new 200 request.

A row marked "(memory cache)" or "(disk cache)" means the browser reused stored content. A 304 still involved a server response, but only headers came back, saving a repeated body transfer. The Size and Transferred columns therefore answer different questions from the file's size alone.

Use Disable cache while DevTools is open to compare with fresh fetches. Throttling simulates a slower connection so you can watch which content appears first. Labels for speed presets vary by browser release.

A failed row without a response status can be a DNS or connection failure; Chrome may show net::ERR_NAME_NOT_RESOLVED. Outside the browser, curl -I https://example.com sends HEAD and prints the status and headers for a quick response check.