Mobile Website Preview
Preview your HTML website at mobile, tablet and desktop widths in HCODX. Check navigation, forms and images before testing on real devices.
What a device preview can—and cannot—tell you
Viewport presets reveal layout behavior quickly, while real hardware remains the final check for touch and rendering differences.
In the HCODX editor, preview controls include desktop, tablet and mobile modes, with a separate responsive tester for more detailed widths and orientation checks. This is valuable after you have written a section: the same navigation, card grid, form or hero can be reviewed across sizes without rebuilding or exporting the project.
A preset is not a phone simulator. The browser still runs on your computer, with its own font rasterization, pixel density, pointer and browser version. Use preview to catch CSS viewport failures early; then open a deployed page on an actual device before calling the experience finished.
Compare the same content
A device pass keeps the source fixed and varies only the viewport, making layout differences easier to identify.
Inspect interactions
Open menus, focus fields and click controls in the frame; a layout that looks fine at rest may fail when a panel expands.
Separate layout from hardware
Viewport width can expose breakpoints. It cannot reproduce every mobile browser quirk, touch target or high-density display.
A useful desktop-to-phone preview pass
Look for failures that are easy to miss when you only inspect the top of a page.
Start wide and scan the hierarchy
Check that the main heading, primary action and navigation are clear at desktop width. A layout can be technically responsive but still bury the important action.
Move to tablet and inspect transitions
Watch multi-column sections, sticky elements and navigation. This middle range often reveals awkward gaps or cards that are just too narrow.
Check phone width in one column
Look for horizontal overflow, clipped code blocks, tiny tap targets, images wider than the viewport and controls whose labels wrap into the icon.
Trigger changed states
Open the mobile menu, reveal an FAQ, submit a form with an error, and focus an input. State changes can create overflow even when the initial page looks clean.
Confirm on a real device
After the viewport pass, test at least one target phone and browser. Check touch, keyboard, font loading and whether the deployed asset paths resolve.
A card row that needs a middle state
The problem is not always the smallest viewport. A two-column layout can fail just above a phone breakpoint.
Imagine three product cards in a row. At wide desktop size they have enough room, and at phone size they stack cleanly. At a tablet width, however, forcing three columns gives each card too little space. Preview that middle width before deciding where the breakpoint belongs.
The exact breakpoint should follow the content. If a heading wraps badly at 850px, move the change there instead of copying a framework preset by habit. Use the responsive HTML editor page for continuous-width testing after this device-mode review.
.cards { display: grid; gap: 1.25rem; grid-template-columns: repeat(3, 1fr); }
@media (max-width: 900px) { .cards { grid-template-columns: repeat(2, 1fr); } }
@media (max-width: 600px) { .cards { grid-template-columns: 1fr; } }Build a small viewport-and-state review matrix
A visual QA pass becomes more reliable when you record exactly which width and state failed, rather than remembering that it “looked strange on mobile”.
A preset is a checkpoint, not a complete device simulation. Repeat the most important flow on actual hardware and the deployed URL.
Review the error state, not just the empty form
The initial form can fit at a phone width while its validation message, label or submit button breaks the layout after interaction.
Paste this form into the editor and inspect it first at a wide preview width, then at a phone preset. Submit it with the email empty and again with malformed text. The browser’s native validation message is not a replacement for a server-side check, but it gives you a real interaction state to inspect. Also focus the field and button by keyboard; a clipped focus ring is easy to miss in a static screenshot.
The example makes the input and button one column at narrow widths. At larger widths the grid uses minmax(0, 1fr) so the field can shrink without forcing the whole row wider. The point is not that 600px is a universal breakpoint; move that threshold to where your actual label, input and button stop fitting comfortably.
<form action="#" method="get">
<label for="email">Email updates</label>
<div class="form-row">
<input id="email" name="email" type="email" required>
<button type="submit">Subscribe</button>
</div>
</form>
<style>
.form-row { display:grid; grid-template-columns:minmax(0,1fr) auto; gap:.75rem; }
.form-row input { min-width:0; padding:.75rem; }
.form-row button { padding:.75rem 1rem; }
@media (max-width:600px) { .form-row { grid-template-columns:1fr; } }
</style>Preset widths, continuous resizing and real devices each catch a different failure
No single preview mode can certify the complete experience.
Preset device modes
Fast, repeatable snapshots at representative desktop, tablet and phone widths. Good for a routine visual pass on every section.
Continuous width testing
Drag across the widths between presets to find the exact point where a heading, grid or navigation item no longer fits.
Real device and deployed URL
Reveals touch behavior, actual browser fonts, safe-area effects, hardware performance and network/asset conditions that a desktop viewport cannot reproduce.
Device preview: practical limits
Review one page at every important width
Use the same source across device modes, then confirm the finished result on real hardware.
Instant HTML Runner & Viewer with Live Preview
Need to run a short HTML, CSS and JavaScript snippet? The HTML Runner Online has a focused editing surface with live output.
Open HTML Runner Online