Guides / Prompting and shipping

How to Make a Website Mobile Responsive

Make any website work on phones: the viewport tag, mobile-first layouts, flexible images, tap targets, tables and forms, plus prompts and a testing checklist.

Mythex Team · 2026-09-29 · 6 min read

To make a website mobile responsive, add a viewport meta tag, build the layout mobile-first with flexible widths, and use CSS breakpoints to rearrange it on larger screens — stacking columns, collapsing the menu and scaling images to fit. Then check every page at phone width for sideways scrolling, tiny text and buttons too small to tap. On an AI-built site, one clear prompt plus a pass in a phone-size preview usually fixes most of it.

What responsive design actually is

A responsive site uses one set of pages and URLs that adapt to the screen. Instead of a separate "m." site, the CSS changes the layout at certain widths, called breakpoints. The building blocks:

• The viewport meta tag tells mobile browsers to use the device's real width.
• Fluid layouts use percentages, flexbox and grid rather than fixed pixel widths.
• Media queries (or framework classes like Tailwind's md:) change the layout above a given width.
• Flexible media — images and video that shrink to fit their container.

It matters because much of your traffic is likely on phones, and because Google indexes the mobile version of your pages. If content or links only exist on desktop, Google may not see them either.

Options and trade-offs

Mobile-first is usually simpler: a single column is the easiest layout, and adding columns as space grows is less work than removing them.

The parts that usually break

The viewport tag

If a page looks like a tiny desktop site on a phone, the viewport tag is missing:

<meta name="viewport" content="width=device-width, initial-scale=1">

Don't add maximum-scale=1 or user-scalable=no. Blocking pinch-zoom makes the site harder to use for people with low vision.

Fixed widths and horizontal scroll

The most common responsive bug is something wider than the screen: a fixed width: 1200px container, a wide table, a long URL or code block, an image without max-width: 100%. The whole page then scrolls sideways. Use max-width instead of width, let text wrap, and give wide things their own scroll area.

Navigation

Five desktop menu links rarely fit on a phone. The usual answer is a menu button that opens a panel. Keep the two or three most important actions visible — "Book", "Cart", "Sign in" — and make sure the menu works with a keyboard and closes easily.

Text and tap targets

• Body text around 16 px is a sensible minimum on phones. Inputs with smaller text make iPhones zoom in when tapped.
• Make buttons and links easy to hit. WCAG 2.2 AA sets a floor of 24 by 24 CSS pixels (or enough spacing); around 44 pixels is more comfortable for thumbs.
• Leave space between adjacent links so people don't hit the wrong one.

Tables and data

Wide tables are the hardest part of a responsive app. Options, in order of preference: show fewer columns on phones, turn each row into a card, or put the table in a horizontally scrollable container with the first column pinned. Pick based on what people need to compare.

Images and media

Use max-width: 100% and height: auto, serve smaller files to small screens with srcset, and set width and height to avoid layout jumps. Embedded videos and maps need a responsive wrapper so they keep their aspect ratio. Smaller images also make pages faster — see how to make your website faster.

Forms

Stack labels above fields, make fields full width, and use the right input types (type="email", type="tel", inputmode="numeric") so phones show the matching keyboard. Put the submit button where a thumb can reach it and keep it visible when the keyboard opens.

Hover-only interactions

Phones don't hover. Tooltips, dropdowns and previews that only appear on hover are invisible to touch users. Make them work on tap too.

Prompts that work

For a new build, say it up front:

Build this mobile-first. Single column on phones, two columns from tablet width, full layout on desktop. No horizontal scrolling at 320 px wide, body text at least 16 px, tap targets at least 44 px, a menu button on small screens, and tables that turn into cards on phones.

For an existing page, describe what you see:

On phones, the /pricing page scrolls sideways and the three plan cards are squashed side by side. Stack the cards vertically below 768 px, make the comparison table scroll horizontally inside its own container with the feature column pinned, and keep the desktop layout unchanged.

Check every page at 375 px wide. List anything that overflows, overlaps, is smaller than 16 px text or 44 px tap targets, or only works on hover, then fix each one.

Step by step

1. Confirm the viewport tag is in the page head.
2. Test at 320–375 px wide in the browser's device mode or a phone-size preview. Scroll every page top to bottom.
3. Fix horizontal scroll first. Find the element that is too wide; everything else is hard to judge until it is gone.
4. Sort out navigation: menu button, key actions visible.
5. Check text, tap targets and forms on each key flow — sign up, search, checkout, contact.
6. Handle tables and media: cards or scroll containers, responsive images and embeds.
7. Check the in-between sizes. Drag the width slowly from phone to desktop; layouts often break around tablet width.
8. Test on a real phone. Emulators miss things like the on-screen keyboard covering a button, notches, and how fast the site feels on mobile data.

Common mistakes

• Only testing at one phone size. Check a small phone, a large phone and a tablet.
• Hiding content on mobile to make it fit. Google indexes the mobile version, and phone users want the same information.
• Disabling zoom in the viewport tag.
• Desktop-sized images on phones, which cost load time and data.
• Fixed-position elements piling up: a sticky header, a cookie banner and a chat bubble can cover half a phone screen.
• Pop-ups that can't be closed on a small screen because the close button is off-screen.

Mobile checklist

• Viewport meta tag present; zoom not disabled
• No horizontal scrolling at 320 px on any page
• Body text ~16 px; inputs don't trigger zoom
• Tap targets comfortably large and spaced
• Menu works on phones and with a keyboard
• Tables readable on phones (cards, fewer columns or scroll container)
• Images and embeds scale; right-sized files served
• Forms use the right input types; submit button reachable
• Nothing important depends on hover
• Tested on at least one real phone

Responsive layout is also part of accessibility: WCAG asks that content works at 320 px wide and at 200% zoom. If you are building an app people will use daily on their phones, how to build a mobile-friendly web app goes further, including installable PWAs.

Responsive design on Mythex

Mythex builds responsive web apps; native App Store apps are coming soon, not available today. In the workspace, click the phone icon above Preview (Switch to Mobile) to see your app in a phone-size frame, and drag the frame's edge to try other widths (Preview and Code). The docs have a short starter prompt for fixing small-screen layout in mobile-responsive prompts. Check on a real phone too — open the published URL, or share a preview link and open it on your phone.