HTML that looks fine in a code editor can fall apart the moment a browser renders it: an unclosed tag swallows a section, a table blows past a phone screen, or an image path points nowhere. The quickest defence is to look before you publish. This guide shows how to use the HTML Viewer to render markup as you edit it, test it at phone and desktop widths, and understand what its sandbox does and does not protect you from.
Where the surprises come from.
Most HTML you handle day to day was not written in a full development setup. It is an email template from a designer, a snippet a CMS exported, a landing page block from an agency, or a widget embed from a vendor. Each one is a few hundred lines you are expected to paste somewhere and trust.
Reading the source rarely catches the real problems. A missing closing div looks harmless in text but pushes the footer inside the sidebar. A fixed width of 800 pixels reads as a number, not as a horizontal scroll bar on every phone. Rendering the markup turns those into things you can see in a second.
The page has two halves. On the left is a code editor with syntax colors, where you paste markup, open an .html file, or load a live page's source by typing its address and clicking Load page source. On the right is the preview, which redraws a moment after you stop typing. If you would rather control when it redraws, untick Update preview as I type and use the Run button.
Above the panes sit the tools you reach for while checking. Format tidies messy indentation so nesting is visible, Minify shrinks the code, Download saves it and Open in new tab shows the page at full window size. Preview width switches between phone, large phone, tablet, laptop and desktop widths, and Height makes the frame shorter or taller to suit the page.
Say a designer sends an order confirmation email built with a 600-pixel table and a two-column product row. Paste the HTML into the viewer and the desktop view looks right. Now set Preview width to Phone (375 px). If the product row keeps its two columns and forces a scroll bar, the template lacks a mobile rule, and you have caught it before any customer did.
Fix it in place: add a media query that stacks the columns below 480 pixels, and the preview updates as you type. Because the frame really is 375 pixels wide, media queries react exactly as they would in a phone browser of that width. Download the corrected file, then send a test through your email platform, since mail apps apply their own rules on top of HTML.
Pasting unknown HTML into a normal page is risky, because any script in it runs with that page's permissions. The viewer avoids this by rendering inside a sandboxed iframe. By default the sandbox blocks scripts completely, so tracking snippets, pop-ups and redirects do nothing while you look at the layout.
When you need interactivity, tick Run JavaScript in the preview. Scripts then run, but the frame still has an opaque origin: it cannot read this site's cookies, storage or page, and forms inside it cannot submit. That makes it reasonable to click through a vendor's widget or test an onclick handler. It is still sensible not to type real passwords into forms from HTML you do not trust.
Gaps to expect.
A preview shows exactly the HTML it is given, which is not always everything the live page uses. These are the usual differences:
Once the page looks right, choose the next step by where the code is going. For a repository or a code review, run it through the HTML Beautifier, which has fuller options for indentation, line wrapping and attribute layout. For an email platform or a CMS field with a size limit, the HTML Minifier strips comments and whitespace and can compact inline CSS and JavaScript as well.
Keep the viewer open while you work in the others. Pasting the final output back in for one last look takes seconds and confirms that neither formatting nor minifying changed how the page renders.
Try it now
The tool is one click away. No sign up, no upload, no payment.
Open HTML Viewer