Open the same website on your father's laptop and then on your mother's phone. On the laptop, the page looks clean — a wide banner at the top, three neat columns of content, comfortable text. Now look at it on the phone. Sometimes it looks exactly as clean, just narrower. But sometimes it looks broken: the text is so tiny you have to pinch and zoom to read a single word, or worse, the page is exactly as wide as it was on the laptop, so you have to scroll sideways just to read one sentence, then scroll back, then scroll sideways again. That second experience is a website that was built for one screen size and never taught how to adapt to another.
In India, for a huge number of people, a smartphone is the only computer they own. When Reliance Jio's cheap mobile data arrived in 2016, tens of millions of first-time internet users came online — and almost all of them arrived on a phone screen, not a laptop screen. A website that only works well at laptop widths quietly locks out most of its own audience. This chapter is about the set of techniques that stop that from happening: making a single web page rearrange itself intelligently for whatever screen it lands on. That property is called responsive design, and it is one of the most practical, testable ideas in web development — you can predict, with arithmetic, exactly how a page will look at a given screen width, and that is exactly what we're going to practise doing.
Why a "fixed" page breaks
Every screen has a width measured in CSS pixels — not the physical dots of the display, but a standard unit browsers use for layout. A budget Android phone might report a width of about 360 pixels. A common laptop screen reports around 1366 pixels. A large desktop monitor might report 1920 pixels or more. If you write CSS that hard-codes a width in pixels, you are making a bet that every visitor's screen is at least that wide.
.container {
width: 1200px;
}This single rule says: "this box is always exactly 1200 pixels wide, no matter what." On a 1920-pixel desktop, that's fine — there's plenty of room, maybe even too much empty space on the sides. But load that same page on a 360-pixel phone, and the browser cannot shrink the box to fit — it was told, explicitly, to be 1200 pixels. The browser's only honest option is to render the box at its full fixed width and let the rest hang off the edge of the visible screen, forcing the visitor to scroll horizontally to see all of it. This is precisely the "tiny text, sideways scrolling" experience described above, and it is the single most common way a beginner's first web page fails on mobile.
The fix is not "use a smaller fixed number." A width of 360px would break on a phone that's narrower, and would look absurdly cramped on a desktop. The real fix has three separate ingredients, and a page needs all three together to be genuinely responsive. We'll build each one from scratch.
Ingredient 1: telling the phone the truth (the viewport)
Here is a fact that surprises most students: even without any of your CSS, a phone's browser does not usually render a web page at the phone's actual screen width. For historical reasons — so that old websites designed only for desktop wouldn't look absurdly broken on early smartphones — mobile browsers default to pretending the screen is about 980 pixels wide, then zooming the whole rendered page out to fit the real, much narrower screen. The result is a page that technically "fits" but whose text is so zoomed-out it's unreadably small, which is exactly why people used to have to pinch-zoom into every website on their phone.
You turn this pretending off with one line in the page's <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">width=device-width tells the browser: "stop pretending you're 980px wide — use the real device width for layout." initial-scale=1 tells it to start at normal zoom, not zoomed out. This is a necessary first step for any responsive page, but here is the first misconception to catch clearly: the viewport tag by itself does not make a page responsive. It only stops the browser from lying about its own width. Without any relative units or media queries, a page with the viewport tag and a hard-coded width: 1200px box will still overflow a 360px phone — it will just overflow at the phone's real width instead of a fake, zoomed-out one. The viewport tag is necessary but not sufficient; it's step one of three.
Ingredient 2: units that scale instead of units that don't
A pixel (px) is an absolute unit — 20px means exactly 20px, everywhere, forever, regardless of screen size. To build a page that adapts, we mostly need units that are defined relative to something else, so that when that "something else" changes, our measurement automatically changes with it. CSS gives us several, and each one is relative to a different thing.
% (percentage) is relative to the size of the parent element. If a parent box is 300px wide and a child is set to width: 50%, the child is 150px wide. If that same page is resized so the parent becomes 800px wide, the child automatically becomes 400px — no extra code needed, the browser recalculates it for you every time the window changes.
vw and vh (viewport width / viewport height) are relative to the entire browser window, not to any parent element. 1vw always equals exactly 1% of the current viewport's width. Let's do the arithmetic, because this is where the "concrete before formal" rule earns its keep: if a phone's viewport is 375px wide, then 10vw = 10% of 375 = 37.5px. Load the identical CSS rule on a 1200px-wide laptop window, and 10vw now equals 10% of 1200 = 120px. Same CSS, same rule, two completely different pixel results — computed automatically, because vw is defined against the live width of the browser window at the moment it renders.
rem ("root em") is relative to the font size of the page's root element — the <html> tag — which browsers set to 16px by default unless you change it. So 1rem = 16px, 2rem = 32px, and 0.5rem = 8px, and critically, this stays true no matter how deeply nested the element is in the page. A heading three levels deep in nested <div>s that is set to font-size: 1.5rem is always 1.5 × 16 = 24px, full stop.
em looks almost identical to rem but is relative to the font size of that element's own immediate parent, not the root. This difference sounds small, but it causes a genuinely common bug, so let's trace it with real numbers. Suppose the root font-size is 16px, and we nest three boxes, each shrinking the next by 0.8em:
.level-1 { font-size: 0.8em; } /* parent is root: 16 * 0.8 = 12.8px */
.level-2 { font-size: 0.8em; } /* parent is level-1: 12.8 * 0.8 = 10.24px */
.level-3 { font-size: 0.8em; } /* parent is level-2: 10.24 * 0.8 = 8.192px */Each em is computed against its own parent's already-shrunken size, so the shrinking compounds — three levels of nesting takes 16px down to about 8.2px, even though every single rule only asked for "80% of my parent." A student who expected each box to be 80% of the original 16px (that is, always 12.8px) has fallen for a real and common mistake. This is precisely why rem exists and why professional stylesheets lean on it for font sizes: it always measures from the one fixed root, so nesting depth can never silently multiply your sizes away. em still has legitimate uses — for example, sizing a button's internal padding so it scales together with that button's own font size — but for page-wide typography, rem is the safer, more predictable default.
Ingredient 3: media queries — rules that only apply at certain widths
Relative units alone give you a page that stretches and shrinks smoothly, but smooth stretching only gets you so far. A three-column layout that simply shrinks its columns down to 80px wide each on a phone is not useful — the columns are technically "responsive" in the sense that they resized, but the content inside them is now unreadable. What you actually want on a narrow phone screen is often a completely different arrangement — three columns side-by-side becoming one column stacked vertically — not just a smaller version of the same arrangement. This restructuring, not proportional shrinking, is what a media query gives you.
A media query is a CSS block that only applies when a condition about the browser window is true — most commonly, a condition on its width:
@media (min-width: 769px) {
.sidebar { display: block; }
}This rule is invisible and inactive at every width below 769px. The moment the browser window is 769px or wider, this rule switches on and the sidebar appears. Shrink the window back below 769px, and the rule switches off again, live, with no page reload — the browser re-evaluates every media query continuously as the window is resized.
There is no single "correct" breakpoint value — it depends on the design — but a widely used convention splits screens into three rough bands: up to about 480px for phones, roughly 481px to 768px for tablets, and 769px and above for laptops and desktops. These numbers are conventions, not laws of physics, but they are common enough that you should recognise them.
A common professional habit — and the one we'll use — is called mobile-first: write your base CSS (with no media query at all) for the narrowest phone layout, then use min-width media queries to add complexity as the screen grows. This matches how you'd naturally think about the problem: start simple, add richness as space allows, rather than starting complex and trying to tear things down for small screens.
Worked example: tracing one page at three widths
Let's put all three ingredients together and trace, with actual numbers, what a real visitor sees. Suppose we're building a page with three content cards — imagine a simple results page showing three subjects from a school report card.
/* Base rules — apply to every screen, phone included */
.cards {
display: flex;
flex-direction: column;
}
.card {
width: 100%;
margin-bottom: 16px;
}
/* Tablet and up */
@media (min-width: 481px) {
.cards {
flex-direction: row;
flex-wrap: wrap;
}
.card {
width: 48%;
}
}
/* Desktop and up */
@media (min-width: 769px) {
.card {
width: 31%;
}
}Now let's trace three real visitors, exactly as a CBSE exam question would ask you to.
Visitor A, phone, 375px wide. 375 is less than 481, so neither media query's condition is true — the browser never even enters those blocks. Only the base rules apply: flex-direction: column stacks the three cards one below the other, and each card is width: 100%, filling the phone's screen edge-to-edge. This is exactly the readable, single-column layout we want on a small screen.
Visitor B, tablet, 600px wide. 600 is greater than 481, so the first media query's condition is now true, and greater than 769 is false, so the second stays off. The base rules still apply first (column, 100%), but the first media query's rules load afterward in the cascade and override them: flex-direction: row plus flex-wrap: wrap puts cards side by side, wrapping to a new row when there isn't space, and each card is now 48% wide. Two 48%-wide cards fit comfortably on one row (96% plus small gaps); the third card, with nowhere left to sit, wraps down to a second row by itself.
Visitor C, desktop, 1024px wide. Now both conditions are true: 1024 ≥ 481, and 1024 ≥ 769. Both media query blocks apply, on top of the base rules, in the order they were written in the stylesheet — this ordering matters, because when two rules both set a property on the same element, CSS lets the one that appears later in the file win. So flex-direction: row still holds from the first block, but width gets set twice: first to 48% by the tablet block, then to 31% by the desktop block, which appears later and therefore wins. At 31% each, all three cards (93% plus gaps) now fit comfortably on a single row.
Notice what just happened: the exact same three <div class="card"> elements, with not one line of JavaScript, silently rearranged themselves from a 1-column stack, to a 2-then-1 wrap, to a clean 3-column row — purely because the browser kept re-checking two width conditions as the screen size changed. That is the whole mechanism of responsive design in miniature: relative units so things scale smoothly, and media queries so the arrangement itself can change shape at chosen widths.
A second misconception worth catching
Beyond "the viewport tag alone makes a page responsive," there's a second mistake worth naming directly: thinking responsive design just means "shrink everything proportionally until it fits." If that were the whole idea, our worked example would have kept three columns at every width, just making each one narrower and narrower — at 375px, each card would be about 125px wide, far too narrow to hold real sentences comfortably. Real responsive design usually changes the structure, not just the scale: three columns become one column; a horizontal navigation bar becomes a collapsible "hamburger" menu icon; a data table with eight columns might hide the four least important ones on a phone and show them only on request. The goal is not "everything gets smaller" — it's "the layout that best fits this amount of space, whatever that layout needs to be."
Where display: flex and display: grid fit in
You may have noticed the worked example used display: flex to arrange cards in a row and wrap them. Flexbox (and its more powerful sibling, CSS Grid) are modern CSS layout systems built specifically to make arranging boxes in rows, columns, and wrapping grids far easier than older techniques. They are genuinely useful tools that pair naturally with media queries — but they are a separate topic in their own right, worth a full chapter of their own. What matters for this chapter is the underlying idea that doesn't change no matter which layout system you use: relative units so sizes scale with their container or viewport, media queries so the arrangement itself can be swapped at chosen breakpoints, and the viewport meta tag so mobile browsers report their real width in the first place. Master those three ingredients and you can make any layout system — flexbox, grid, or even old-style floats — genuinely responsive.
Reading the diagram
The figure below shows one page's content — a navigation bar and three cards — rendered at three different viewport widths side by side. Look carefully at what changes between them: it is not just the size of the boxes, it is their arrangement.
Check your understanding
- A stylesheet has
:root { font-size: 16px; }and a heading rulefont-size: 2rem. What is the heading's font size in pixels? Now suppose that same heading is nested four<div>s deep — does the answer change? Why or why not? - Using the three-card CSS from the worked example, what layout and card width would a visitor at exactly 481px wide see? (Careful: is the tablet media query's
min-width: 481pxcondition true or false at exactly 481px?) - A page has
10vwset as a box's width. On a 320px-wide phone, how many pixels wide is the box? On a 1440px-wide monitor, how many pixels wide is it? Explain, using your two answers, whyvwwould be a poor choice for body text size but can be a reasonable choice for a full-width banner image. - A classmate says, "I added the viewport meta tag to my page, so now it's responsive." Explain what is wrong with this statement, and name the two additional ingredients their page still needs.
- Why does a mobile-first stylesheet use
min-widthmedia queries rather thanmax-widthones for its breakpoints? What would go wrong if the base (no-media-query) styles were written for desktop instead of phone?
Summary
A responsive page is one that rearranges itself correctly across the huge range of screen widths real visitors actually use — and in India, where a smartphone is often someone's only device, that range starts very narrow. Getting there needs three ingredients working together, not any one alone. The viewport meta tag stops mobile browsers from faking a wide, zoomed-out layout and makes them report their true width. Relative units — % against a parent, vw/vh against the live viewport, and rem against the fixed root font size (with em's parent-relative behaviour understood as the one that can compound unexpectedly across nested elements) — let sizes scale smoothly instead of staying frozen in absolute pixels. And media queries, most cleanly written mobile-first with min-width conditions, let you swap the entire arrangement of a page — not just its scale — at chosen breakpoints, because the best layout for three columns is often not a shrunken version of itself but a genuinely different, one-column, structure. Given any CSS with media queries, you should now be able to do exactly what we did in the worked trace: pick a viewport width, work out which conditions are true, apply the rules in the order they're written, and predict precisely what a real visitor on a real screen would see.
Practice Exercises
Now it is time to practice! Complete these challenges to solidify your understanding:
- Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
- Exercise 2: Find a real-world example where responsive is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
- Exercise 3: Create a mind-map connecting responsive to at least 3 other topics you have studied.