HTML Preview
Live HTML, CSS, and JS editor with instant preview
关于此工具
Write HTML, CSS, and JavaScript in three separate editor panes and see the result rendered live in an iframe — no build step, no server. Choose from preset templates to get started quickly, toggle between split editor/preview and full-preview modes, and share your snippet by copying the full source. Perfect for prototyping layouts, testing CSS animations, or debugging scripts.
使用方法
- 1 Choose a preset template from the dropdown, or start with a blank canvas.
- 2 Edit the HTML, CSS, and JS tabs — the preview pane updates as you type.
- 3 Click 'Preview Only' to expand the preview to full width for a better look.
- 4 Use 'Copy Source' to grab the complete HTML document for use elsewhere.
How a live preview works without a server
This tool takes your three editor panes — HTML, CSS, and JavaScript — and stitches them into one complete document. It wraps your CSS in a <style> tag, drops your HTML into the body, and appends your JavaScript inside a <script> tag, producing a full <!DOCTYPE html> page. That string is fed to an <iframe> through its srcdoc attribute, which tells the browser to render the string as if it were a real page loaded from a URL. There is no build step, no compiler, and no server round-trip: the browser's own rendering engine paints your markup the instant the document changes. Because everything happens locally, the preview works with your network disconnected.
The sandbox: what runs and what's blocked
The preview iframe is deliberately restricted with a sandbox attribute set to allow-scripts allow-modals. In practice that means your JavaScript executes and alert() or confirm() dialogs pop up, but the iframe is isolated from the page hosting it — your code cannot reach into this site's DOM, read its cookies, or navigate the top window. Treat the preview exactly as you would a local .html file you double-clicked: it is your code running in your browser, fully capable, but walled off from everything around it. This is also why pasting untrusted third-party code is no riskier here than opening it locally, and no safer either.
Debounced updates: why it waits a beat
The preview does not re-render on every keystroke. Each edit schedules an update and cancels the previous one, so the page only rebuilds about 400 milliseconds after you stop typing. This "debounce" keeps the editor smooth — without it, rebuilding the whole document on every character would stutter, and a half-typed tag or unterminated string would flash broken intermediate states. The practical effect: type freely, pause, and the result appears. If a change doesn't show, you usually just need to stop typing for a moment.
A worked example
Load the Counter App template. The HTML pane defines a number display and three buttons; the CSS centers and styles them; the JS grabs the elements by ID and wires up click handlers that increment, decrement, and reset a variable. Click + in the preview and the number rises — proof that your JavaScript is genuinely executing, not just being displayed. Now change let n = 0; to let n = 100; in the JS tab, pause, and the counter starts at 100. You have edited running code and seen the effect without saving a file or refreshing anything.
Loading external libraries
Because the iframe renders a complete page, it can pull in resources from a CDN just like any website. Add <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap.../bootstrap.min.css"> in the HTML pane to style with Bootstrap, or a <script src="..."> tag to load a library before your own script runs. This requires a network connection for those specific requests, even though the core preview itself does not. The default template's picsum.photos image is a small example of the same mechanism.
Tips and common mistakes
- Don't paste a full HTML document into the HTML pane. This pane is the body content. Adding your own
<html>,<head>, or a second<style>nests a document inside a document and produces unpredictable results. Put styles in the CSS tab and scripts in the JS tab. - Order matters for scripts. Your JS runs after the HTML is in place, so element lookups by ID work. But a library loaded via a CDN
<script>tag in the HTML pane must appear before code that depends on it. - Use "Preview Only" to judge layout. Toggling to full-width preview gives a truer sense of responsive behavior than the narrow split view.
- Copy Source is your save button. The tool keeps nothing between sessions; copy the combined document and paste it into a
.htmlfile to keep your work. - Sandbox blocks some APIs. Features that need same-origin access or top-level navigation may not behave as they would on a deployed site; test those in a real page.