HTML Viewer: Preview HTML Code Live

What an HTML viewer is for

An HTML viewer renders markup so you can see the page instead of the code. Paste a snippet, an email template, a file someone sent you, or the output of a script, and the preview on the right shows exactly what a browser draws. Edit the code and the preview refreshes about a third of a second after you stop typing.

It is the fastest way to answer questions like: does this email template still look right after my change, what does this saved .html file actually contain, why is this component collapsing on mobile, and did my CSS selector match anything at all.

Why the preview is sandboxed

Viewing untrusted HTML is a real security question. A file from an unknown sender can contain scripts that try to read cookies, open pop-ups, or redirect the page. This viewer renders your code inside an iframe with the sandbox attribute and without allow-same-origin. That gives the preview a unique, opaque origin. Its scripts cannot read this site's cookies or storage, cannot touch the page around it, and cannot navigate the top window.

Scripts are allowed by default so interactive snippets work, like the click counter in the example. Untick Run JavaScript to render HTML and CSS only. That is the safer choice for files you do not trust, such as a phishing email you want to inspect.

Nothing is uploaded. The code goes from the text box straight into the iframe's srcdoc attribute, all inside your browser. There is no server that could log it.

Worked example: checking a responsive layout

Paste a card component with a max-width and some padding. On Desktop it sits centered with space around it. Click Mobile and the preview narrows to 375 pixels, the width of a typical iPhone. If the card has a fixed width of 420px, you will now see a horizontal scrollbar. Change width: 420px to max-width: 420px and the card shrinks to fit. That loop, edit and check at three widths, catches most layout bugs before they ship.

Media queries respond to the preview width, because the iframe is its own viewport. A rule like @media (max-width: 600px) kicks in when you switch to Mobile, just as it would on a real phone.

Tips for faster previews

Include everything in one file. The preview has no folder around it, so relative links such as <link href="style.css"> or <img src="logo.png"> have nothing to load. Put CSS in a <style> block, and use full https:// URLs or data URIs for images.

External resources still load. Google Fonts, CDN scripts, and images on public URLs work, because the browser fetches them normally. Resources that need your login cookies will not, since the sandbox has no access to them.

Email templates are a special case. Real email clients strip <script>, ignore many CSS properties, and Outlook on Windows renders with Microsoft Word's engine. A preview here shows what a browser renders, which matches Apple Mail and most webmail clients reasonably well, but always send a test email before a campaign.

Use the formatter first. If the code arrives minified, run it through the HTML formatter so you can find the part you want to edit.

Pitfalls

Alerts and prompts. alert() and confirm() are allowed in the preview, so a runaway loop that calls alert() can be annoying. Untick Run JavaScript to stop it.

Storage APIs. Because the preview has an opaque origin, localStorage, sessionStorage, IndexedDB, and cookies are unavailable inside it. Code that relies on them will throw a security error. That is the sandbox doing its job.

Forms submit into the void. Forms render and validate, but submitting navigates the iframe away from your code. Re-type a character to reload the preview.

The Tab key indents. Inside the code box, Tab inserts two spaces so you can edit comfortably. Press Esc, then Tab, to move focus to the next control.