Home / Guides / Live HTML preview

Guide · Updated June 21, 2026

How live HTML preview works—and how to debug it without guessing

A live preview turns source code into a browser document every time the editor changes. The useful part is not merely seeing the result: it is understanding which document is being rendered, which resources it can reach and what the browser reports when something fails.

Open the editorRead the short answer

What is a live HTML preview?

A live HTML preview is a browser-rendered document that refreshes as its HTML, CSS or JavaScript source changes. In a single-file editor, the preview can be generated directly from one complete HTML string, which makes feedback nearly immediate. In a multi-file project, the preview also needs an entry document, a virtual or real base URL and resolvable paths for stylesheets, scripts, images and fonts. The preview uses the browser’s normal parsing, layout and JavaScript engines, so valid web-platform behavior still applies. It is excellent for prototyping, learning and reproducing front-end bugs, but it is not automatically identical to production: server routes, build tools, environment variables, HTTP headers and backend APIs may be absent. A reliable workflow therefore combines fast visual feedback with console inspection, explicit file paths and a final test on the intended hosting environment.

Start with a complete document

A browser can repair incomplete markup, but relying on that repair makes debugging harder. Begin with a doctype, a language, character encoding, viewport metadata, a title and a body. The WHATWG HTML Living Standard defines the document model, while MDN’s HTML reference offers practical explanations and compatibility notes.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>Preview test</title>
  <style>body { font-family: system-ui; padding: 2rem; }</style>
</head>
<body>
  <h1>Hello preview</h1>
  <script>console.log('Preview ready');</script>
</body>
</html>

Choose the right editing mode

Use Simple mode when the work fits naturally in one document: a component demo, a CSS experiment, a teaching example or a bug reproduction. Inline styles and scripts remove path resolution from the equation, so the visual response can be as direct as possible.

Use Files mode when the folder structure is part of the behavior. A stylesheet linked with `<link rel="stylesheet" href="styles.css">` and a script loaded with `<script src="script.js"></script>` require the preview to know where `styles.css` and `script.js` live relative to the active HTML file. The multi-file guide explains that resolution model.

A debugging sequence that saves time

  1. Check the entry document. Confirm that the preview is rendering the HTML file you think it is rendering.
  2. Reduce to visible HTML. Add a plain heading. If it does not appear, the problem is earlier than CSS or JavaScript.
  3. Check relative paths and filename case. Hosting systems may distinguish `Logo.png` from `logo.png` even if a local operating system does not.
  4. Inspect the console. Syntax errors, blocked resources and missing files usually provide a precise URL and line number.
  5. Test the exported result. Open the downloaded HTML or serve the folder over HTTP before treating the preview as production proof.

Responsive preview is a viewport test, not a device laboratory

Changing the preview width is useful for media queries, fluid layout, overflow and component wrapping. It does not emulate every mobile property: the CPU, memory, touch input, browser chrome, safe areas and network conditions remain those of the current device. Use the responsive sizes for fast layout checks, then verify important flows on a real phone or with browser device emulation.

Include a viewport meta tag or mobile widths can behave like a scaled desktop canvas. Prefer layouts that respond to available space instead of targeting a catalogue of device models. CSS media queries are documented in the MDN media query guide.

Security and preview boundaries

JavaScript in a preview can run code with the permissions granted to its frame. A sandbox can reduce some capabilities, but more restrictive policies may also break legitimate examples, downloads, forms or multi-file navigation. Do not paste untrusted code into a permissive environment. For sensitive testing, use an isolated browser profile or a disposable environment.

When a live preview is the wrong tool

A static preview is not a replacement for a Node.js build, a server-side framework, a database or an API. Imports that depend on package resolution, framework compilation, secret environment variables or server routes need their actual runtime. The preview remains useful for the generated HTML/CSS/JS layer, but the final verification belongs in the target stack.

Common mistakes to rule out first

Do not debug a complex animation before confirming that the expected HTML entry is active. Do not add `!important` repeatedly when the stylesheet itself may be missing. Avoid testing a module only through `file://`, because origin restrictions can create errors that disappear over HTTP. Finally, remember that a blank preview is not evidence of a slow renderer: malformed markup, a full-page overlay, white text on a white background or an early JavaScript exception can all produce the same visual symptom.

Next: learn how an entry file and relative URLs work in the multi-file HTML editor guide.