One Website, Two Very Different Screens
Suppose your father books a train ticket on the IRCTC website using the desktop computer at home, and later that evening your mother opens the exact same website on her phone to check the PNR status. If the website were built the old-fashioned way — with every box, button and font size fixed in pixels for a large monitor — your mother's phone would try to cram that same wide layout into a screen one-third the width. The result: text so small she would have to pinch and zoom just to read the "Check Status" button, and she would need to scroll sideways just to see the whole page. This is not a rare accident. It is what happens to any website that was designed assuming only one screen size exists.
A responsive website is one that notices how much space it has been given and rearranges its own content to fit — without the visitor having to zoom, scroll sideways, or squint. The same HTML, the same information, reflows itself differently depending on whether it is displayed on a 24-inch monitor, a 10-inch tablet, or a 6-inch phone. This chapter is about exactly how a browser is taught to do that: which measurements to use, which instructions ("media queries") let a page ask "how wide am I right now?", and which layout tools let boxes flow and wrap instead of overflowing or shrinking to illegibility.
A Concrete Starting Point: Chai in Different Cups
Before touching any code, hold on to one everyday idea. If you pour the same 150 millilitres of chai into a tall, narrow glass, the liquid rises high and thin. Pour that exact same 150 millilitres into a short, wide cup, and it spreads out low and broad. The amount of chai — the content — never changed. Only its shape changed, because it adapted to the container it was poured into.
A responsive webpage does the same thing with its content. The paragraph you are reading right now, the navigation menu, the images — none of that information changes between a laptop and a phone. What changes is how it is arranged: three columns side by side on a wide screen become one column stacked top to bottom on a narrow screen, the way chai reshapes itself to its cup. Web design struggled with this for years because early CSS measurements were like pouring chai into a cup of a fixed, unchangeable shape carved in stone — 800 pixels wide, always, no matter what container it was actually poured into. Responsive design replaces the stone cup with a flexible one.
Culprit Number One: the Invisible Viewport
Here is a fact that surprises most students the first time they hear it: a phone's screen and a phone's browser viewport are not automatically the same width. Unless a webpage explicitly says otherwise, many mobile browsers assume they are rendering a page designed for a desktop — roughly 980 CSS pixels wide — and then shrink that entire 980-pixel-wide layout down to fit the phone's actual screen.
Let's do the arithmetic, because it explains exactly why old websites look microscopic on phones. Say a phone has a real screen width of 360 CSS pixels (a common width for many Android phones). If the browser assumes the page is 980 pixels wide and scales it down to fit into 360 pixels, the scale factor is:
scale factor = actual screen width / assumed page width
scale factor = 360 / 980
scale factor ≈ 0.367
Now take a paragraph of text set at a normal, readable 16 pixels. After that automatic shrink, it renders at:
16 px × 0.367 ≈ 5.9 px
Six pixels tall is close to unreadable — smaller than the print on a medicine strip. This is precisely the tiny-zoomed-out effect you have seen on badly built websites. The fix is one line placed inside the page's <head>:
<meta name="viewport" content="width=device-width, initial-scale=1.0">This tag tells the browser: "Do not assume 980 pixels. Set the viewport width equal to the device's actual width (device-width), and start at 100% zoom (initial-scale=1.0)." Without this single line, none of the other responsive techniques in this chapter will work correctly — the browser will keep shrinking your carefully designed layout to fit its assumed 980-pixel canvas. This is why the viewport meta tag is always the very first step, before a single media query is written.
Building Blocks: Relative Units Instead of Fixed Pixels
The second reason old pages break on new screens is that their measurements were absolute. A box declared as width: 800px is always 800 pixels, whether the screen is 360 pixels or 2560 pixels wide — on the narrow screen it simply cannot fit, forcing sideways scrolling. Responsive design instead prefers units that are defined relative to something else, so the same rule automatically produces different results on different screens.
- Percentage (%) — relative to the parent container's size.
width: 50%inside a 1000-pixel-wide container gives 500 pixels; the same rule inside a 360-pixel-wide container gives 180 pixels. The rule never changes, but the result adapts. - em — relative to the font size of the current element's parent. This is the tricky one, explained numerically below.
- rem ("root em") — relative to the font size of the root
<html>element only, no matter how deeply nested the element is. Browsers default the root font size to 16 pixels unless a designer changes it. - vw / vh — relative to the viewport itself: 1vw equals 1% of the current viewport width, 1vh equals 1% of the current viewport height. These are useful for elements that should scale with the screen itself rather than with a parent box.
Converting between pixels and rem is simple arithmetic once you fix the root size at 16px:
rem value = pixel value ÷ 16
24px ÷ 16 = 1.5rem
40px ÷ 16 = 2.5rem
Misconception to correct: many students assume em and rem behave identically because both are "relative" units. They do not. em compounds with nesting; rem never does. Trace this carefully:
html { font-size: 16px; } /* root size */
.card { font-size: 1.25em; } /* 1.25 × 16px = 20px */
.card .title { font-size: 1.5em; } /* 1.5 × 20px = 30px, NOT 1.5 × 16 */
Notice that .title's 1.5em is measured against its immediate parent .card (20px), not against the root (16px), giving 30px. If three more nested boxes each added 1.2em, the sizes would keep multiplying — a common bug called "em compounding" that makes deeply nested text unpredictably huge or tiny. Had the same rule used 1.5rem instead, it would always compute to 1.5 × 16px = 24px, regardless of how deep the nesting goes, because rem always looks at the root, never the parent. This is why most responsive stylesheets prefer rem for font sizes and reserve em for spacing that should genuinely scale with a specific local font size, such as padding inside a button that should grow if that button's own text is enlarged.
Media Queries: Teaching a Page to Notice Its Own Width
Relative units alone make a layout flexible, but they cannot change the fundamental arrangement — say, going from three columns to one. For that, CSS provides media queries: conditional blocks of CSS that only apply when the browser window matches a stated condition, most commonly a minimum or maximum width.
The syntax reads almost like an English sentence:
@media (min-width: 600px) {
.card { flex: 1 1 45%; }
}
This says: "If the viewport is at least 600 pixels wide, apply this rule to every element with class card." The width mentioned in a media query is called a breakpoint — the screen width at which the layout deliberately changes shape.
Modern responsive design is built mobile-first: you write the plain, un-conditioned CSS rules for the smallest screen first, then use min-width media queries to progressively add more columns as more space becomes available. This is the reverse of how many beginners guess it should work (design for desktop, then shrink for mobile), and the reason mobile-first wins is practical: a very large share of visits to Indian websites — including e-commerce, exam-result portals, and school sites — now come from phones, so the simplest, most reliable layout should be the default, with extra layout complexity added only when the screen can afford it.
Worked Example: A Three-Card Layout Across Three Screens
Imagine a page showing three subject cards — say, "Artificial Intelligence", "Python Programming", and "Web Development" — that should sit in one column on a phone, two columns on a tablet, and three columns on a desktop. Here is the complete, mobile-first CSS:
.container {
display: flex;
flex-wrap: wrap;
gap: 16px;
}
.card {
flex: 1 1 100%; /* default: full width, one per row */
}
@media (min-width: 600px) {
.card { flex: 1 1 45%; } /* two per row */
}
@media (min-width: 900px) {
.card { flex: 1 1 30%; } /* three per row */
}
Notice the numbers are 45% and 30%, not the "obvious" 50% and 33.3%. That gap is deliberate: two cards at exactly 50% plus a 16px gap between them would add up to slightly more than 100% of the container's width, forcing the second card onto a new line early. Leaving a small margin (45% × 2 = 90%, with the remaining space absorbed by the gap and rounding) keeps two cards comfortably on one row.
Now trace what actually happens at three real screen widths, applying the rules in the order they are written:
- At 375px (a phone): Neither media query's condition (
min-width: 600pxormin-width: 900px) is true, since 375 is less than both. Only the base rule applies:flex: 1 1 100%. All three cards stack in a single column, one per row. - At 700px (a small tablet): 700 ≥ 600, so the first media query's rule applies, giving
flex: 1 1 45%. 700 is not ≥ 900, so the second query never fires. Two cards fit per row; the third card wraps to a second row alone. - At 1024px (a laptop): Both conditions are true (1024 ≥ 600 and 1024 ≥ 900). Both media query blocks technically match. When two CSS rules of equal specificity both apply, the browser uses the one that appears later in the stylesheet — the "cascade" in Cascading Style Sheets. Since the
min-width: 900pxblock was written after themin-width: 600pxblock, itsflex: 1 1 30%wins. All three cards sit in a single row.
This trace reveals exactly why mobile-first media queries must always be written in ascending order of their breakpoint. If a student accidentally wrote the 900px block before the 600px block, then at 1024px both rules would still match, but now the 600px rule (appearing later) would win — silently overriding the intended three-column layout with an incorrect two-column one, even though the screen is wide enough for three. This is a genuine, easy-to-make bug, and checking the source order of media queries is one of the first things to inspect when a responsive layout "looks wrong" only at certain widths.
Flexible Images: Stopping Pictures From Breaking the Page
Text can reflow naturally, but an <img> tag has an intrinsic pixel size baked into the image file itself — say, 1200 by 800 pixels. If that image is placed inside a card that has shrunk to 340 pixels wide on a phone, and no rule tells the image to shrink too, the image will simply overflow its container at its full 1200-pixel width, forcing the whole page to scroll sideways. The standard fix is two CSS declarations applied to every image:
img {
max-width: 100%;
height: auto;
}
max-width: 100% tells the image it may never be wider than its parent container, whatever that container's current width happens to be — 340px on a phone, 900px on a laptop. height: auto is equally important: it tells the browser to recompute the image's height in the same proportion as the width shrank, preserving the original aspect ratio instead of squashing the picture. Trace the numbers: a 1200×800 image (ratio 3:2) placed in a 340px-wide card becomes 340 pixels wide; height auto-scales to keep the 3:2 ratio, giving 340 × (800/1200) ≈ 227px tall. Without height: auto, a fixed pixel height like height: 800px would keep the image 800 pixels tall while its width shrank to 340, visibly stretching and distorting it.
A Second Misconception: "Responsive" Is Not the Same as "A Separate Mobile Site"
Many students confuse two different strategies. Some websites once built (and a few still maintain) an entirely separate version of their site at an address like m.example.com, with its own HTML served only to phones — this is called an adaptive or separate-site approach. It works, but it means maintaining two codebases, and it can break in confusing ways — for instance, if a phone user pastes a desktop link, they may land on the wrong version, or a search engine may index the wrong page. Responsive design is a different, generally preferred strategy: there is exactly one HTML document and one CSS file, and that single file uses relative units and media queries to reshape itself for whatever screen loads it. Most modern Indian government portals, school websites, and e-commerce sites now favour this single-codebase responsive approach over maintaining a separate mobile site, precisely because it is easier to keep one set of content accurate and up to date, and there is no risk of the "wrong" version being shown.
Choosing Breakpoints Sensibly
A common early mistake is choosing breakpoints based on specific, named devices — for example, writing a media query for exactly 390px because "that's the width of a particular phone model." This backfires the moment a new device with a slightly different width appears, or when a user simply resizes a browser window on a laptop. The professional convention instead chooses breakpoints based on content: test the layout by slowly resizing the browser window and note the width at which the design starts to look cramped or the text lines become too long to read comfortably — that width becomes the breakpoint, regardless of which specific device happens to produce it. This is why the breakpoints used earlier in this chapter (600px, 900px) are common, round, device-independent numbers rather than exact phone or tablet dimensions.
Quick Recap
- Responsive design means one page, one codebase, that reflows its own layout based on available width — like chai reshaping itself to whichever cup it is poured into.
- The viewport meta tag (
width=device-width, initial-scale=1.0) must come first, or the browser will keep assuming a roughly 980px-wide desktop layout and shrinking everything, sometimes down to unreadable ~6px text. - Relative units (%, em, rem, vw, vh) let sizes scale with their context instead of staying fixed.
remalways refers to the root font size (default 16px);emcompounds with each level of nesting, which can silently multiply sizes if not tracked carefully. - Media queries (
@media (min-width: ...) { }) apply CSS conditionally based on viewport width. Mobile-first design writes the plain rules for small screens first, then layers onmin-widthrules for wider screens — and those rules must be written in ascending width order, because when multiple queries match, the one later in the source wins. max-width: 100%; height: auto;on images stops them from overflowing their container while preserving their original aspect ratio.- Breakpoints should be chosen by watching where a real layout starts to look cramped, not by copying a specific device's screen width.
Practice: Test Yourself
- A page's root font size is 16px. Convert 32px and 20px into
remvalues. - A parent element has
font-size: 1.5emand the root is 16px. Its child hasfont-size: 1.2em. What is the child's actual rendered font size in pixels? Show each step. - A phone has an actual screen width of 360 CSS pixels and no viewport meta tag is present, so the browser assumes a 980px-wide page. What scale factor is applied, and what does 18px text become after scaling (to one decimal place)?
- Using the three-card CSS from the worked example in this chapter (base rule 100%,
min-width:600px→ 45%,min-width:900px→ 30%), predict how many cards appear per row at a browser width of 640px, and explain which single media query condition is true. - A classmate writes their stylesheet with the
min-width: 900pxblock appearing before themin-width: 600pxblock. At a screen width of 1200px, which rule actually wins, and why? Is the resulting layout the one the student intended? - Explain, in your own words, why an
<img>element needs bothmax-width: 100%andheight: autotogether, and what visibly goes wrong if only one of the two is used. - A friend says, "Responsive design just means making the text smaller for phones." Identify what is missing or incorrect about this description, using at least one term (viewport, media query, or relative unit) from this chapter.