What is responsive design
Responsive design means one page, one URL and one set of content whose layout changes with the width of the viewport, instead of separate versions for mobile and desktop. The widths where the layout changes do not come from a list of devices; they come from the places where your own layout breaks.
- Lesson 5 of 12
- Beginner
- Free, no signup
One layout, and the widths it has to work at
The column is viewport width. The three chips below are this site own three real bands.
- Below 640 pixelsThe most used boundary on this site. Everything becomes a single column.
- 641 to 1100 pixelsTablet and small laptop. The header is still the mobile bar.
- 1101 pixels and upThe desktop header and the mega menu switch on.
320 is a floor, not a target, and 1200 is the content column ceiling of this site, not a standard. Your own number comes from where your own layout breaks.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What exactly does responsive mean?
Responsive design means one HTML file, one URL and one set of content that rearranges itself at any width. Three columns side by side on a laptop, the same three stacked on a phone. Nothing is removed and no second address is created.
It was not the only way. For years two others were common: a separate site on a mobile subdomain, and serving different HTML from the server based on the device. Both still work and both are twice the work, because every change has to be made in two places. Google own mobile-first indexing document says that with responsive design the content and the metadata are the same on the mobile and the desktop version, and it documents those other two setups separately.
In practice one line switches this on. Without it a mobile browser lays the page out on a virtual canvas around 980 pixels wide and then shrinks it, which is exactly the page you have to pinch to read:
<meta name="viewport" content="width=device-width, initial-scale=1">On this site that line sits on line fourteen of the theme header.php. It does not matter how many media queries you write; without this one, none of them behave the way you expect.
Why start from the narrowest state?
Because being narrow forces you to prioritise. In one narrow column everything surplus announces itself: the decorative banner, the sidebar nobody reads, the three buttons that sat next to each other for a reason that no longer holds. Start from desktop and you never make those decisions, you only hide them later with CSS.
In code you have two routes. Write the base state narrow and add the wider widths with min-width, or write the base state as desktop and retreat with max-width. For a new public site take the first: a mobile browser processes no extra rules and your CSS does not pile up with every added breakpoint. For rebuilding an old desktop-only site the second is more honest; you cannot pretend the thing that exists does not.
Let us also end one misunderstanding here: mobile first is an order of writing, not a licence to ship less on mobile. Google says plainly that the content of the mobile version should be equivalent to the desktop version and that you should complete it if it is less. The design may differ; the content may not.
Start narrow or start wide? Both are real choices
The difference is not capability, it is the starting point and whether your site is new or old.
Start narrow, with min-width
- The base state carries no media query and is one column
- A mobile browser processes no extra rules
- Content priority is settled from the start
- The right pick for a new project
Start wide, with max-width
- The base state is the desktop layout you already have
- Less painful for making an old site responsive
- Every breakpoint adds one more layer of overrides
- Tracing gets harder as the queries pile up
Mixing the two in one file is exactly where CSS gets away from you. Pick one and stay with it across the project.
Where does a breakpoint number come from?
From your own layout, not from a list of devices. This is the most important sentence in the lesson and most tutorials say the opposite: the numbers 768, 992 and 1200 that get repeated everywhere are a framework default and have nothing to do with your site.
The way to find yours is boring and reliable. Open the page and narrow the window a notch at a time. Wherever a heading wraps badly, a column crushes, or something pokes out sideways, that width is your breakpoint. Write the number down and carry on. A normal page produces three or four numbers, not ten.
The live example is this site. The theme main.css has 43 media query blocks, which together make 17 distinct width boundaries: 430, 580, 600, 640, 700, 720, 780, 820, 860, 880, 900, 920, 980, 1100, 1259, 1299 and 1359. Not one of them is 768 or 992. There are more blocks than boundaries because some boundaries are written twice, once with max-width and once with min-width one pixel higher: 640 and 641, 1100 and 1101. Each number has its own story: below 1100 the glass desktop header gives way to the mobile bar, and below 780 any content table with three columns or more turns into stacked cards, because a three column table is not readable on a phone.
One point that takes a long time to learn: a breakpoint belongs to a component, not to a page. A card sitting inside a narrow column does not break at the width of the window; it breaks at the width of its own container. That is why @container was added to CSS, and it is why the same card can be placed in two spots on one page and be right in one and wrong in the other.
Relative units, containers, and images that reserve their space
A media query is the last tool, not the first. A layout written with relative units from the start passes most widths with no query at all. Give widths in percentages or with fr in a grid, set type in rem, and where it genuinely helps use clamp() so one value moves smoothly between two bounds. px has its place for a border or a small gap; for the width of a block, usually not.
Constrain the container, not the screen. This site has a variable called --wrap set to 1200 pixels, and the content column never grows past it however large the monitor is. The reason is not taste: when a line of text gets too long, the eye loses its place on the way back to the start of the next one.
Right to left enters here, and it is more than a detail. Write margin-inline-start instead of margin-left and the same single CSS file serves Persian and Arabic as well as English and Turkish, with the browser taking the direction from dir on the html tag. That claim is countable on this site: across the whole of main.css there are seventy logical property declarations and zero uses of margin-left, margin-right, padding-left or padding-right.
And images. Every img needs width and height, even when CSS resizes it. From the ratio of those two the browser holds the space open before the file arrives, so the text underneath does not jump as it loads. Put srcset and sizes alongside them so a phone fetches the small version rather than the desktop one. On the blog posts of this site every image carries both, and the featured image offers two widths, 720 and 1200 pixels.
What to check, and what responsive is not
Check these
- The viewport tag is in the head
- No sideways scroll at 320 pixels
- At 400 percent zoom the content is still readable
- Every image has width and height
- Buttons and icons are at least 24 by 24 pixels
- The same desktop content is present on mobile
These are not responsive
- Hiding half the page on mobile with display none
- Shrinking the whole page with zoom instead of relaying it out
- Building a separate mobile subdomain
- Copying a framework breakpoints without testing
This list does not replace a test on a real phone. The browser simulator does not simulate a finger, and it does not simulate a slow connection either.
Three checks before you call it responsive
First, 320 pixels. The Reflow criterion in WCAG says content must be usable at a width equivalent to 320 CSS pixels without scrolling in two dimensions. Most people assume that number is about old phones, but the document own point sits elsewhere: 320 CSS pixels is the equivalent of a 1280 pixel viewport at 400 percent zoom. So the criterion is really about someone whose eyes need the page enlarged, not about a handset.
Second, the size of anything meant to be touched. Another criterion in the same standard says pointer targets should be at least 24 by 24 CSS pixels unless there is enough spacing around them. Footer icons crowded together and delete buttons inside a table are the two places this usually fails.
Third, the content. Does the version you see on the phone say what the desktop version says? If a block is hidden on mobile with display: none, that block is effectively faded for Google too, because indexing is done from the mobile version.
And one exception W3C states itself: content that is inherently two dimensional, such as a large data table or a map, is excluded from the criterion. The answer for something like that is not to cram it into 320 pixels; it is to let that one thing scroll inside its own container while the rest of the page does not.
The fast path, with AI
Language models write media queries in seconds. What they cannot do is know where <em>your</em> layout breaks, and because they cannot, they reach for the numbers the tutorials repeat. So the fast path is not asking the model for breakpoints; it is measuring them yourself and letting the model write only the CSS. A fast cheap model is enough here, because turning a list of numbers into a few rules is mechanical work; our current pick is in <a class="text-link" href="/en/ai/">the AI section</a>.
- Open the page and narrow the window a notch at a time. Note every width where something genuinely breaks, with one sentence: what broke and how. Three or four widths is normal.
- Take only the CSS of that one component, not the whole file. The model works better with fifty lines than with five thousand, and you read the output more easily too.
- Fill the recipe below with your widths and descriptions, and run it.
- Put the CSS in and narrow again. If a new break appears, add it to the list and run the recipe again; do not staple another query onto the output by hand.
- Check the last two yourself: 320 pixels, and the size of the buttons on a real phone. No model does those two for you.
Copy-ready recipe
This is the CSS for the {component name} component:
{paste the CSS here}
The layout breaks at these widths:
- {width}px: {what breaks}
- {width}px: {what breaks}
Write the smallest set of media queries that fixes only these breaks.
Rules:
1) Use min-width. The base state, with no media query, must be the narrow state.
2) Use margin-inline-start and padding-inline-end instead of margin-left and padding-right.
3) Use no fixed px widths except the numbers I gave you.
4) Add no breakpoint that is not in my list above.
5) Above each query write a one line comment saying why exactly that number.
Output CSS only.Before you trust the output: The model does not see your page; it sees only what you pasted. If you measured the numbers wrong, the output implements exactly that mistake, neatly. And two things are outside its reach: the 320 pixel test and touching a button with a finger on a real phone. Those two are yours.
AI in this kind of work
For responsive work AI is good at writing the rule and bad at choosing the number. That is our position: let it write the CSS, never let it choose the breakpoint. Three uses that genuinely save time: turning a fixed layout into a relative grid, explaining why a rule has no effect at a particular width, and rewriting an old file into logical properties for right to left.
Tools that actually help
- Claude Good at rewriting a long CSS file into logical properties and explaining it line by line. Iran is on neither of Anthropic two supported-countries lists; we read that on Anthropic own page.
- Gemini Enough for short questions about one rule and for getting a grid version of a layout, and it handles Persian well. Google own page says the Gemini web app runs in over 230 countries and territories, and Iran is not on that list.
- ChatGPT The most common choice and acceptable for these jobs. We make no claim here about its access or pricing: OpenAI supported-countries page returns 403 to our server, and we do not write a claim with nothing behind it.
Where it backfires
The main risk here is the number. Models were trained on a decade of tutorials and framework defaults, and in our own use we have repeatedly seen that when you do not give them a width they reach for 768 and 992, numbers that do not appear even once in the whole of this site main.css. The result is a site that looks fine in the simulator and breaks at the width a real user has. The second risk is subtler: a model cannot judge what it has not measured. It does not compute a contrast ratio from text and it does not run a reflow test, and W3C own Easy Checks guidance says automated review does not replace human review. So measure the numbers yourself and ask the model for the rule. For how each tool can be paid for from Iran, see the buying guide.
Sources: W3C: Understanding SC 1.4.10 Reflow W3C WAI: Easy Checks Anthropic: supported countries Google: where Gemini Apps are available
Where this advice stops
A responsive layout and a good mobile experience are not the same thing. A page that sits correctly at every width is still bad if it stays blank for three seconds on a slow connection or its buttons cannot be hit with a thumb; that conversation belongs to the site speed path. Second, content that is inherently two dimensional, such as a large data table, does not collapse into 320 pixels, and the standard itself excludes it. Third, if you are using a ready made theme most of these decisions are already made; your job is not to rebuild but to check.
From our own work
The rule that a breakpoint belongs to your layout can be counted on this very site. On the day this lesson was checked, the main.css of the rgb.ir theme had 43 media query blocks making 17 distinct width boundaries between them, the smallest 430 and the largest 1359. Not one of them is 768 or 992, which means not one came from a device list or a framework default. The number 1200 does appear in that file, but not as a breakpoint: it is the value of the --wrap variable, the ceiling on the content column width. And one more number countable in the same place: across the whole file there are seventy logical property declarations and zero uses of margin-left or padding-right, for a simple reason; that one file has to drive right to left Persian and Arabic as well as English and Turkish. All of this can be recounted with a single grep over the same file.
Real follow-up questions
Is responsive different from mobile friendly?
Yes. Responsive is an implementation: one page whose layout changes. Mobile friendly is an outcome: a page that is usable on a phone. A site can be responsive and still be bad on mobile, for instance because it is slow or its buttons are tiny.
How many breakpoints do I need?
As many as the places your layout breaks, and no more. A normal page ends up with three or four. If you reach ten, that usually means the base layout was written in fixed units and you are patching it with queries.
Does a responsive site rank better?
Being responsive is not a ranking bonus in itself. What matters is that Google indexes from the mobile version, so whatever is not on mobile effectively does not exist for Google. Responsive is the most popular way to reach that parity, not the only one.