HTML Live Renderer
Safely preview HTML code in a sandboxed iframe. Supports mobile, tablet, and desktop size presets.
HTML Code
Paste HTML code here...
Preview
Full width
Quick Start
Pick an example to instantly load and preview the rendered output.
About HTML Live Renderer
The HTML Live Renderer lets you write and preview HTML code instantly in the browser. All rendering happens inside a sandboxed iframe, so previewed scripts cannot touch the parent page or your local data.
It supports three device presets — mobile, tablet, and desktop — plus an auto-render mode that refreshes the preview as you type, no button click needed.
How to Use
- Paste or write your HTML code in the editor panel
- Pick a device size (mobile / tablet / desktop) to match your target screen
- Watch the live preview update on the right; enable auto-render to skip the button click
Common Mistakes & Best Practices
- Missing viewport meta tag: Always include <meta name="viewport" content="width=device-width, initial-scale=1.0"> for mobile previews. Without it, the page renders at desktop width and scales down, making mobile/tablet previews inaccurate.
- External resources blocked: The sandbox iframe security policy blocks external CDN scripts, stylesheets, and fonts. Workaround: inline all CSS and JS directly in your HTML instead of referencing external URLs.
- Character encoding not declared: Always include <meta charset="UTF-8"> in <head>. Without it, non-ASCII characters (Chinese, emoji, etc.) may render as garbled text.
- JavaScript dialogs blocked: The sandbox attribute disables alert(), confirm(), and prompt() dialogs. Use console.log for debugging or render results directly into the DOM.
Real-World Production Scenarios
After scraping a dynamically rendered page, paste the captured HTML into the sandbox to confirm that your XPath / CSS selectors still hit the target nodes. Faster than reloading the live site through DevTools repeatedly, and unaffected by the source site's IP throttling, CAPTCHA, or A/B experiments.
Email clients (Outlook, Gmail, QQ Mail) carry decades of inline-style + table-layout baggage. Edit HTML in the sandbox and see the result instantly, eliminating the soul-crushing "tweak → send test email → wait → screenshot compare" loop. Iteration speed jumps at least 10x.
HTML emitted by TinyMCE / Quill / wangEditor often carries editor-specific classes, inline styles, and private nodes. Rendering the output in an isolated sandbox prevents style bleed-through from the editor itself, showing exactly what end users will see on the consumer-facing page.
Inspect external ad codes, user-submitted UGC, or Markdown-to-HTML output for XSS payloads, hidden tracking scripts, and auto-redirects before they hit production. The sandbox confines script execution to the iframe, away from parent cookies — safe to combine source review with visual inspection.
Want to validate a hero section, card grid, or form visually? No need to spin up Vite or a dev server. Drop HTML + inline CSS into the sandbox, switch between mobile / tablet / desktop sizes without code changes, and review in seconds.
Deep Dive: iframe Sandbox & Render Isolation
The sandbox attribute is the heart of HtmlRender. Empty sandbox="" (no value) is the strictest mode — no JS, no form submission, no same-origin access. Add allow-scripts to enable JS execution; add allow-same-origin to let the iframe share the parent's origin (so it can access localStorage, etc.). The tool defaults to sandbox="allow-scripts allow-same-origin" — a debug-friendly compromise that still isolates the parent DOM.
Combining allow-scripts with allow-same-origin is a common trade-off: scripts run, and the iframe can read its own localStorage. The catch: if the iframe HTML is untrusted, an attacker can use the same-origin context to call parent.document and hijack the parent page. For production rendering of UGC, drop allow-same-origin and keep only allow-scripts, forcing the iframe into a null origin.
srcdoc vs src: HtmlRender uses srcdoc instead of src="data:text/html,...". srcdoc is a native attribute — no URL length limit (data: URIs hit Chrome's 2MB cap on large HTML), no base64 encoding, and changing srcdoc auto-reloads the iframe without an explicit reload(). The trade-off is that very old browsers (IE10 and earlier) don't support it, but IE11+ is fine.
External resource loading: sandbox does not directly block external fetches, but CSP and the browser's cross-origin font / CORS checks will block a meaningful chunk of them. The production recommendation is to inline everything — CSS in <style>, fonts via data: URIs, icons via inline SVG. If a CDN is truly required, add an explicit <meta http-equiv="Content-Security-Policy"> inside the HTML to allow the needed origins, avoiding the "works most of the time" mystery bugs.