Free HTML Preview / Code Playground
Write HTML, CSS and JavaScript in the editors below and see the result instantly in the preview pane.
How It Works
- Paste or type HTML: Enter your HTML code (full documents, fragments, templates, or email HTML) into the editor.
- See the live render: The preview panel shows exactly how the browser renders your HTML in real time.
- Iterate quickly: Edit and preview in a tight loop without switching browser tabs or saving files.
Why Use HTML Preview?
When writing HTML for templates, emails, components, or static pages, you need constant feedback on how the markup renders. Opening files in a browser and refreshing manually breaks your workflow. This HTML Preview tool renders your HTML instantly as you type, giving you a live visual preview in the same window, ideal for rapid iteration on templates, debugging layout issues, and testing HTML emails before sending.
Features
- Real-time rendering: Preview updates as you type with no delay or manual refresh.
- Full HTML support: Renders complete documents with <head>, <style>, and <body> tags, or plain HTML fragments.
- Isolated sandbox: The preview runs in a sandboxed iframe, preventing scripts from affecting the page.
- Responsive preview: Resize the preview pane to test how the HTML looks at different viewport widths.
- Error display: HTML errors are logged so you can catch broken tags and invalid markup.
Frequently Asked Questions
Can I preview HTML emails?
Yes. Paste your email HTML including inline styles and table-based layouts. The preview renders exactly as an email client would. Note that external fonts and some CSS features may behave differently in actual email clients.
Does external CSS and JavaScript work?
External stylesheets loaded via <link> tags may not load due to CORS restrictions in the sandboxed preview. JavaScript execution is limited by the sandbox. For the best results, use inline CSS. External resources from CDNs that allow cross-origin access will load normally.
Can I use this to test responsive designs?
Yes. Drag the preview panel width to simulate different screen sizes, or use the viewport presets (mobile, tablet, desktop) to test your responsive breakpoints.
How Live Preview Works: iframe srcdoc
The <iframe> element was introduced in HTML 4.0 (December 1997) to embed one document inside another. For two decades the only way to populate an iframe was via the src attribute pointing at a URL. The srcdoc attribute, allowing you to pass the iframe's HTML inline as a string, was added in HTML5 (W3C Rec, October 2014) and is now supported by every modern browser. srcdoc is what makes a browser-based HTML preview tool possible without server upload: you write HTML, the tool wraps it in <iframe srcdoc="...">, the browser renders it in an isolated context, and nothing crosses the network.
The sandbox Attribute and the Same-Origin Trap
<iframe sandbox> was introduced in HTML5 to apply a per-iframe security policy. With no value, the most restrictive sandbox applies: same-origin restricted (treated as a unique origin), scripts disabled, forms disabled, top-level navigation disabled, plugins disabled, pointer lock disabled, popups disabled, auto-play media disabled. You opt back in by adding tokens: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation, etc. Each token opens one specific capability.
The combination to never use is sandbox="allow-scripts allow-same-origin" simultaneously: this allows JavaScript to call document.domain and walk back up to the parent window, completely defeating the sandbox. Browsers warn about this in DevTools when you set both. This preview tool sets allow-scripts and explicitly NOT allow-same-origin, so user JS runs but can't read or write the parent page's DOM, cookies, localStorage, IndexedDB, or service-worker caches.
Content Security Policy, the Second Line of Defence
A separate-but-related defence is Content-Security-Policy, an HTTP response header introduced in W3C CSP Level 1 (Candidate Recommendation, November 2012). CSP Level 3 is the current standard. The key directive for preview tools: frame-src (which iframes can be loaded) and script-src (which inline/external scripts can run). Even if a malicious payload escaped the sandbox, the host page's CSP would still apply and forbid most exfiltration paths. Defense in depth: the sandbox isolates the iframe's code, and the host's CSP limits what the host page can do if the iframe somehow influenced it.
Email-Client HTML Is Its Own World
A preview that renders modern browser HTML does not render email HTML. Major email clients use very different engines: Gmail web uses a WebKit-based renderer with class-stripping and limited <style>-tag support (added 2016). Apple Mail / iOS Mail use WebKit, the most permissive renderer. Outlook desktop (2007 through 2019) renders HTML email through the Microsoft Word rendering engine: no <style> block support, no flex/grid, no positioned elements, no animations; background images need VML conditional comments. This Outlook quirk is the single biggest issue in email development. Outlook 365 web is modern WebKit. The "new Outlook" rolled out 2023-2024 uses Edge WebView2. For real email-client previews, use a paid service like Litmus or Email on Acid.
Responsive Breakpoints to Test
The CSS media-query breakpoint conventions trace to Ethan Marcotte's May 2010 "Responsive Web Design" article in A List Apart. The two dominant frameworks chose different cutoffs:
- Bootstrap 5 breakpoints (since version 4, October 2016):
576px / 768px / 992px / 1200px / 1400pxfor sm / md / lg / xl / xxl. - Tailwind CSS breakpoints:
640px / 768px / 1024px / 1280px / 1536pxfor sm / md / lg / xl / 2xl. - Standard device widths: iPhone SE 375×667, iPhone 14/15 390×844, iPad 768×1024, iPad Air 820×1180, desktop 1280×800 / 1440×900 / 1920×1080, 4K 3840×2160.
HTML's Standards Lineage
Quick reference for the standards your preview is rendering against: HTML 2.0 (RFC 1866, November 1995), the first official spec from Tim Berners-Lee, established the basic tag set. HTML 4.01 (W3C Rec, December 1999) added <script>, <style>, <table>, frames. XHTML 1.0 (W3C Rec, January 2000) attempted a strict XML serialization, mostly abandoned by 2010. HTML5 (W3C Rec, October 2014) added semantic elements (<article>, <section>, <nav>), canvas, video/audio, web storage. In May 2019, WHATWG took over stewardship from W3C, and HTML is now maintained as a Living Standard at html.spec.whatwg.org, continuously updated.
Common Use Cases
- Email-template prototyping (knowing the iframe render won't match Outlook).
- Quick HTML / CSS scratchpad when you don't want to start a CodePen account.
- Demo-recipe building for blog posts or documentation.
- Teaching HTML basics to students with instant visual feedback.
- JS algorithm visualization, combining HTML/CSS structure with small JS scripts.
- Form behaviour testing without spinning up a server.
- A11y experimentation, testing
aria-*attributes, role models, tab order.
Common Mistakes
- Trying to read the iframe's contents from the parent. With
sandboxset, cross-origin restrictions block it. The iframe canpostMessageout, but the parent can't reach in. - Pasting CSS that targets
bodyand being surprised the tool's own body styles aren't affected. The iframe is a separate document with its own DOM. - External resources blocked by CSP. An
<img src="https://example.com/x.png">may load fine in your preview but get blocked when you copy the same code to a CSP-locked production site. - Forgetting
DOMContentLoadedfires in the iframe, not the parent. Scripts inside the iframe see their owndocument, not the tool's. - Setting both
allow-scriptsandallow-same-originin a sandbox tool, completely defeating the purpose. Browsers warn about this combination in DevTools.
More Frequently Asked Questions
Why doesn't my localStorage work in the preview?
localStorage and sessionStorage require allow-same-origin in the sandbox attribute. Since combining that with allow-scripts would defeat the sandbox, this preview blocks storage by design. Your code will throw a SecurityError on the first localStorage.setItem. For testing storage-dependent code, run it on a real origin (a local dev server, for example).
What JavaScript version does the preview support?
Whatever your browser supports. The iframe runs the same JS engine as the parent page, so a Chrome user gets V8, a Firefox user gets SpiderMonkey, a Safari user gets JavaScriptCore. Modern features (optional chaining, top-level await, classes, async/await, ES2024 syntax) work if your browser supports them. For older-browser-target testing, paste in transpiled output from Babel or swc.
Can I load external scripts and stylesheets?
Yes for most public CDNs. <script src="https://cdn.jsdelivr.net/..."> and <link href="https://cdn.tailwindcss.com" rel="stylesheet"> usually work because those CDNs set permissive CORS headers. Resources that require credentials or are origin-locked will fail. The Network panel in your browser's DevTools shows exactly which resources loaded and which were blocked.
How is this different from CodePen / JSFiddle / StackBlitz?
Those are full code-hosting services with save / share / fork / collaboration features and require accounts. This tool is a single-page scratchpad: no account, no saving, no sharing, no analytics. Paste, preview, iterate, close the tab. For something you want to keep or share, CodePen is still the better option.
Is my code uploaded anywhere?
No. The HTML / CSS / JS you paste is wrapped in <iframe srcdoc="..."> on the same page and renders in a sandboxed unique origin in your browser. No network call carries your content. External resources your HTML references (images, scripts, stylesheets) are fetched by your browser the same way they would be on any web page, but the source code itself never leaves the page.