WebToolArcWidth testing is not device emulation
The preview changes the sandboxed iframe CSS width so responsive layouts can be checked quickly. Device pixel ratio, platform fonts, browser UI and touch behavior are not emulated.
Home / HTML Tools / Responsive HTML Preview
HTML Tools
Responsive HTML Preview
Paste HTML, choose or enter a viewport width, inspect the sandboxed rendering, and compare source statistics without uploading the markup.
390 pxPreview width
0Source bytes
0Source lines
0Source tags
Viewport approximationThis changes the iframe CSS width. It does not emulate device pixel ratio, browser chrome, mobile browser quirks, installed fonts or real touch/input behavior.
Multi-viewport comparison lab
Render the same HTML source at three explicit CSS viewport widths side by side. Frames stay sandboxed with scripts disabled, so this is a layout comparison rather than full device emulation.
Ready.
Use this result with confidence
Compare several widths before declaring a layout responsive
A page that works at one phone width can still fail between common breakpoints. Test at least a narrow phone, a tablet-sized width, and a desktop width, then add a custom width around any breakpoint where navigation or columns change. The comparison panel uses the same HTML source across all frames so differences come from viewport width rather than edited content.
Viewport width is not full device emulation
An iframe sized to 390 pixels exercises CSS media and container queries at that width, but it does not reproduce a specific phone browser, GPU, safe-area inset, virtual keyboard, network, or touch behavior. Use this tool for layout inspection, then verify critical interactions on real target browsers and devices before release.
Keep scripts disabled for untrusted snippets
HTML previews are most useful when the input is treated as untrusted markup. The comparison frames stay sandboxed and do not enable scripts, which prevents pasted code from acting like a normal page. If a component depends on JavaScript, test it in a controlled local development environment instead of weakening the preview boundary.
Look for reflow, clipping, and reading-order problems
Do more than check whether the page fits. Watch for horizontal scroll, text cutoffs, overlapping controls, images that dominate the viewport, and content that changes reading order at narrow widths. A screenshot-like visual pass is helpful, but keyboard order and semantic structure still need a real accessibility audit.