HTML Viewer
Preview HTML markup in a sandboxed live viewer.
What is HTML Viewer?
An HTML viewer is a developer tool that takes raw HTML markup and renders it inside an isolated browser frame so you can preview what the page or fragment looks like without saving a file, spinning up a local server, or trusting the markup to access your main browsing context. The output frame uses the same rendering engine as the rest of your browser, which means the preview matches what real users would see when the same markup is served from a domain.
This HTML viewer wraps the rendered output in a sandboxed iframe, which blocks the markup from reading cookies, making same-origin network calls, or navigating the parent tab. Designers, frontend developers, and content editors use it to preview email templates, CMS snippets, marketing landing copy, and component output before pasting the markup into a production system.
Why use the HTML Viewer?
- Preview markup instantly. Pasting HTML renders it on the spot, with no file save, no
localhostserver, and no build step in between you and the rendered result. - Isolate untrusted markup safely. The preview runs inside a sandboxed iframe, so even hostile or buggy markup cannot read your session, your storage, or the parent page.
- Inspect email and CMS snippets. Block-style email HTML and CMS-pasted fragments often render fine in isolation but break in their host. The viewer shows the isolated case first so you can rule out host-specific bugs.
- Debug templating output. Drop the response body from a server-rendered endpoint or a static-site build to confirm the framework emitted the markup you expect.
- Stay private with internal content. The markup never leaves your browser. Internal landing pages, draft copy, and unreleased designs stay on your device.
How to use the HTML Viewer
- Paste your HTML into the HTML textarea. A full document with
<!DOCTYPE html>works, and so does a single fragment like<h1>Title</h1><p>Body</p>. - Watch the Preview panel below the textarea render the markup live as you type or paste.
- Adjust the markup in the textarea and the preview updates on the next render tick.
- To compare two versions, swap the markup in the textarea, the preview redraws against the new input.
- If the preview is empty, the textarea is empty. If the preview looks broken, validate the markup with the HTML Validator to find unclosed tags.
How safe rendering works
The viewer wraps the input in an iframe element with the sandbox attribute set to allow-scripts only. The sandbox attribute, defined in the HTML Living Standard, removes a long list of capabilities by default and re-grants only the tokens you opt into. Because no allow-same-origin token is granted, the iframe is treated as a unique opaque origin: it has no access to cookies, localStorage, sessionStorage, or any cross-frame DOM on the parent page.
<iframe
srcdoc="<your markup here>"
sandbox="allow-scripts"
title="HTML Preview"
></iframe>The markup is passed via the srcdoc attribute rather than a src URL, so no network request is made and the parent never serializes your input into a server log. Scripts inside the iframe execute in the iframe’s own opaque origin and cannot touch the host page.
Sandbox limitations
The sandbox is strict on purpose, which means a few things the markup might expect to work will fail in the preview.
| Capability | Status in preview | Why |
|---|---|---|
Inline <script> | Runs | allow-scripts is granted so scripted demos work. |
fetch() and XMLHttpRequest | Same-origin requests fail | The frame has an opaque origin, not your domain. |
Cookies and localStorage | Empty | No allow-same-origin means no persistent storage. |
window.parent.location | Throws | Cross-origin DOM access is blocked. |
| Form submission | Blocked | allow-forms is not granted. |
| Top-level navigation | Blocked | allow-top-navigation is not granted. |
| Pop-ups | Blocked | allow-popups is not granted. |
| External CSS and images | Loads normally | Network requests for assets are allowed. |
If your markup depends on cookies, same-origin storage, or form submissions to render correctly, the preview will look broken even though the markup itself is valid. Test those flows in a real browser tab served from your own domain instead.
Common use cases
- Frontend developers reviewing component output. Drop the rendered HTML from a React or Vue component to confirm semantics, spacing, and class names look right before committing.
- Email developers previewing newsletter HTML. Inline-styled email markup renders cleanly here, which lets you spot layout bugs before the template hits a real inbox client.
- Content editors checking CMS snippets. Paste the rich-text output from a WordPress or Contentful editor to confirm headings, lists, and images render as intended.
- QA engineers verifying a bug report. Reproduce a markup-related layout glitch in isolation by pasting the affected fragment, ruling out CSS bleed from the host page.
- Designers prototyping landing pages. Paste a static landing-page mockup into the viewer to share a live preview link with stakeholders without deploying.
Frequently asked questions
Is the HTML viewer safe for untrusted markup?
Yes for the markup itself. The sandboxed iframe cannot read your cookies, your storage, or the parent page’s DOM, so a malicious snippet cannot exfiltrate session data. It can still display content that is visually unpleasant or socially engineered, so apply your own judgment before rendering markup from unknown sources.
Why do my external scripts not run?
External scripts load and execute, but if they expect to talk to a same-origin backend, the request will fail because the iframe has an opaque origin. Scripts that only manipulate the DOM, animate elements, or compute values inline work fine. Scripts that call document.cookie or localStorage.getItem will get empty values.
Does this render markup the same way Chrome does?
Yes. The preview uses your current browser’s rendering engine. Chromium-based browsers render the preview with Blink, Firefox with Gecko, and Safari with WebKit, identical to how the same markup would render if served from a real domain in that browser.
Will it execute JavaScript inside the HTML?
Yes. The sandbox grants allow-scripts, which means inline <script> tags and external scripts run. If you need a script-free preview, strip the scripts before pasting or use a different tool that disables script execution.
Can I save the preview as a screenshot?
Not from inside this tool. Use your browser’s built-in screenshot shortcut or a screenshot extension to capture the preview area. For bug reports that need a screenshot plus console and network context, ShotMark captures all of that with one click.
Is the markup uploaded anywhere?
No. The markup lives in browser memory and is passed to the iframe via the srcdoc attribute, which never touches the network. There is no analytics event, no server log, and no autosave for the textarea contents.
Why does my page look different in the preview than in production?
The iframe has no parent CSS to inherit from. If the production page relies on a global stylesheet, a CSS reset, or a CDN-hosted font, the preview will look unstyled or fall back to system fonts. Include the relevant <link rel="stylesheet"> tags in your pasted markup to match production styles.
Can I view large HTML files?
Yes, up to a few megabytes. The srcdoc attribute holds the full markup as a string, so files in the tens of megabytes can slow down the tab. For very large documents, save the file locally and open it directly in a browser tab instead.
Related tools
- HTML Validator. Check HTML markup for structural errors before previewing.
- CSS Validator. Validate CSS syntax against W3C parsing rules.
- HTML Prettify. Reformat HTML with consistent indentation and line breaks.
- Credit Card Validator. Verify card numbers with the Luhn algorithm.
Related tools
ShotMark captures what you do here, in one click.
The traces, payloads, and tests you run by hand? ShotMark grabs the whole bug and hands it to your AI agent.