How to Test HTML on Phone, Tablet, and Desktop Sizes Without Deploying

Every layout looks great at the width it was designed at. The question that decides whether your page embarrasses you is what it looks like at every other width, and with AI-generated sites this matters double, because models overwhelmingly design at desktop width and most of your visitors will arrive on a phone.

The good news: you do not need to deploy anything, own a tablet, or borrow phones to find out. Here are the two ways to test, when each is right, and the specific bugs to hunt for.

Method 1: paste and flip through device sizes

The fastest loop, especially for code straight out of ChatGPT, Claude, or Gemini, is a previewer with device presets. In MarkUpTo, switch to Web mode, paste your HTML, and the page renders inside a browser frame. Then flip through:

• Desktop, 1440 × 900, the width the AI probably designed at
• Laptop, 1280 × 800
• Tablet, 768 × 1024, where multi-column layouts start to strain
• Phone, 390 × 844, the truth-teller

There is also a custom width slider from 320 to 1920, which is the honest way to find your breakpoints: drag it slowly and watch where the layout snaps or breaks. Media queries and responsive frameworks respond to the preview width exactly as they would to a real window, because the preview is a real rendering viewport, not a scaled screenshot.

Two extras make this loop practical. Scripts run live, so interactive bits (menus, tabs, accordions) can be clicked, not just admired. And the screenshot button captures the full page length at the current width, which is the artifact you actually want when sharing progress with a client or a group chat: the entire phone-width page as one tall image, not a cropped viewport.

Method 2: your browser's DevTools

Fair is fair: every desktop browser ships a serious testing tool. Open your HTML file, press F12 (or Cmd-Option-I on a Mac), and click the device toolbar icon. You get named device profiles, touch simulation, network throttling to feel the page on slow connections, and the ability to inspect exactly which CSS rule is causing a problem.

DevTools is the deeper instrument, and if you are debugging why something breaks, it is the right one. The paste-and-preview route wins on the everyday loop where the code is in your clipboard rather than in a file, you want four widths checked in twenty seconds, and you want a shareable full-length screenshot at the end. Most people end up using both: preview to find problems, DevTools when a problem needs an autopsy.

What to actually look for at each size

A checklist worth running at phone width, where nearly all the crimes happen:

• Horizontal scrolling. If the page scrolls sideways even slightly, something has a fixed width wider than the screen: an image, a table, a container with a hard pixel width.
• Columns that should stack. Three feature cards side by side at 1440 need to become a vertical stack on a phone. AI layouts frequently forget the breakpoint.
• Text overflow. Long words or headings escaping their boxes, buttons whose labels wrap into ugliness.
• Type that ignores the screen. A 64 pixel desktop headline that fills the whole phone viewport, or body text shrunk below comfortable reading size.
• Touch targets. Links and buttons need finger-sized room; a row of tiny nav links that were fine with a mouse is misery on glass.
• Image behaviour. Photos should scale down inside their containers, not push the layout wide or distort.

At tablet width, watch for the awkward middle: two-column layouts that are too cramped for two columns and too empty for one. At large desktop, check that content does not stretch into unreadable full-width lines; good layouts cap their content width.

Turning findings into fixes, cheaply

When something is broken, precision is money. Going back to the AI with "make it responsive" invites a full rewrite that may disturb what works. Going back with the specific failure gets a targeted patch: "at widths under 640px, stack the three pricing cards vertically and reduce the hero heading to 32px." One clear sentence, one clean fix.

And for the small stuff you can see yourself, wording, a colour, a padding value, skip the AI entirely and edit directly in the previewer, because every re-prompt regenerates the whole file. The economics of that are laid out in stop wasting tokens on small edits.

The two-width rule

If you remember one thing: test at 390 and 1440. A layout that holds at a modern phone width and a full desktop width almost always behaves in between, and the whole check takes under a minute once pasting-and-flipping is your habit. Then ship it, following the five-minute hosting guide, knowing the first phone visitor sees what you meant them to see.

The widths that matter, on one card

Width	Stands in for	What breaks here
320 px	The smallest phones still in pockets	Absolute worst-case overflow; if it survives 320, it survives
390 px	Current mainstream phones	Unstacked columns, giant headings, sideways scroll
768 px	Tablets, half-snapped windows	The awkward middle: two columns cramped, one column sparse
1280 px	Laptops	Usually safe; check nav spacing
1440+ px	Desktops and monitors	Content stretching full-width into unreadable line lengths

One subtlety: fragments test differently than full pages

If the AI gave you a fragment (code starting mid-page with a div rather than a doctype), how it renders depends on what wraps it. A previewer that auto-wraps fragments with the framework they expect shows you the design as intended; the same fragment saved as a bare file shows unstyled soup, which can send you hunting a responsive bug that does not exist. Test the version you will actually ship: if the fragment will live inside an existing site, paste it into that context for the final check, because the surrounding page's styles can change spacing and fonts. And when a client or friend needs to see the state of things, send the full-length phone-width screenshot rather than the code, since "here is exactly how it looks on a phone" ends more debates than a paragraph of description ever has.

A sixty-second routine you will actually keep

Testing regimes fail when they are ceremonies, so here is the whole discipline as a habit-sized loop. Paste the code. Look at desktop, since that is what the AI intended. Jump straight to phone and run the checklist above, which after a week you will do on sight in ten seconds. Drag the custom slider from narrow to wide once, watching for a snap or a sideways scrollbar. If anything broke, either click-fix it on the spot or write the one-sentence bug report for the AI. Screenshot the phone view for the group chat. Done. Sixty seconds per iteration is cheap enough that you will actually run it on every version, and every-version checking is what keeps the broken layout from ever reaching the person whose opinion of you matters.

Frequently asked questions