HTML Live Runner
Write HTML+CSS+JS on the left, live preview in the iframe on the right. Run and clear supported.
Code runs in an iframe sandbox and never leaves your browser.
HTML live runner: what the iframe sandbox can and cannot do
How the preview is built
The preview on the right is an iframe. You write HTML, CSS and JS on the left, hit run, and the code is placed inside that iframe to render. The key feature is that your code executes in a separate document environment, not injected straight into the current page. That gives two direct benefits:
- Style isolation. A
body { background: red }inside the preview will not paint the tool page red. Every CSS rule you write applies only within the iframe document. - Script isolation. The preview's JS gets the iframe's own window and document and cannot accidentally touch the tool itself. This also means running someone else's snippet is far safer than "just executing it" — the isolation browsers recommend for code-sharing sites.
Relative-path resources will not load
The most common confusion: an <img src="./logo.png"> or a <link href="/style.css"> will not show in the preview.
The reason is no base URL. The preview content is an independently injected document that belongs to no real server directory, so relative paths have nothing to resolve against. Three workable options:
| Option | Note |
|---|---|
| Use a full URL | https://example.com/logo.png loads (if the other side allows cross-origin) |
| Inline the resource | turn images into data URIs, put CSS in a <style> block, JS in a <script> block |
| Use a CDN link | for frameworks or fonts use a full CDN address (unpkg, jsdelivr) |
The second option is exactly where this site's "image to Base64" tool earns its keep: turn an icon into a data URI and paste it into the preview with no external dependency.
Network requests and cross-origin limits
The preview can use fetch or XMLHttpRequest, but the browser same-origin policy applies:
- Calling a third-party API, the other side must return CORS headers allowing cross-origin. Many public APIs do, many do not.
- A request to
file://or a local path returns nothing. - Do not test API calls that carry keys here — the key travels in the browser's request and can be logged in the devtools network panel.
What it can and cannot do
| Good for | Not for |
|---|---|
| quickly checking an HTML/CSS layout | projects needing a build step (bundling, transpiling, module resolution) |
| trying CSS properties, animation, transitions | projects depending on npm packages (unless a CDN build exists) |
| testing string handling, regex, date logic | Node.js code (file system, process, native modules) |
| showing someone a minimal runnable example | full back-end features (login, persistence, database) |
| verifying behaviour in a minimal environment | performance benchmarks (iframe differs from a real page) |
On the last row: render timing, font loading and resource priority all differ inside an iframe, so performance numbers measured here are only indicative, not authoritative.
Peculiarities of the preview environment
- Viewport size. The iframe width is limited by the page layout, so
100vw, media-query breakpoints andvhunits are measured against the iframe size, not the real browser window. For responsive behaviour use the device-emulation mode in devtools, not the preview box. - Default styles. The iframe has its own UA defaults (the body's default margin and so on). So your layout "has a little extra margin" is normal — real projects usually reset or normalize first.
- Cookies and storage. The iframe's access to the current site's localStorage is limited by isolation, so storage-dependent code may misbehave.
- Form submission behaves differently. A form submit tries to navigate the iframe, with behaviour unlike what you expect; test interaction with event listeners, not a real submit.
How the tool works
Edit HTML on the left (you can embed <style> and <script>), hit run, and the right iframe renders instantly. Everything stays local — the code never leaves your device, which is essential when testing internal page structure, unpublished components or snippets with business logic. To debug, right-click the iframe and choose Inspect to see its DOM and console in devtools — the direct way to trace a JS error in the preview.
FAQ
Can I include external JS libraries?
Yes, include a CDN with <script src="..."> in the code, but only reference sources you trust.