The HTML Viewer on this page is a live editor for HTML, CSS, and JavaScript. Paste or type code on the left and see it rendered in a sandboxed iframe on the right, immediately and continuously as you edit. The editor uses CodeMirror for syntax highlighting and line numbers, and the preview is fully isolated from this page — your code cannot read cookies, touch local storage, or affect anything outside the preview frame.
This is a different kind of tool than a Markdown viewer or a code beautifier. The HTML Viewer is for the moments where you have a snippet of HTML and want to see what it does, not what it looks like in source. That includes prototyping a small layout, sanity-checking an AI-generated component before pasting it into a real project, debugging an email template, reviewing the HTML inside a pull request, or showing a colleague what some markup actually renders to.
The sandbox attribute on the preview iframe is set to allow-scripts only — not allow-same-origin. That combination lets scripts in your HTML execute (so a click handler will work, an animation will run, a fetch can be attempted), while preventing those scripts from accessing this page, your CalcMojo cookies, your localStorage, or your real browsing context. The preview is a true black box.
Use the Sample button to load a working demo (HTML with inline CSS and a click handler in JavaScript) and see the editor and sandbox in action. Then clear it and paste in your own HTML.
What is an HTML Viewer?
An HTML Viewer is a tool that takes raw HTML source code and shows you what that code renders to inside a real browser context. Unlike a documentation viewer or a beautifier, it actually executes the code: stylesheets style, scripts run, animations animate, fetches attempt to fetch. It is the smallest possible “live coding” environment, focused on a single document.
Tools in this category have existed for years — JSFiddle, CodePen, CodeSandbox, JSBin, html.onlineviewer.net — but most of them either require a signup, target a specific use case like sharing a fiddle, or bury the single-document use case behind a multi-file project shell. The HTML Viewer here is intentionally minimal: paste HTML, see what it renders to, copy or download the result. Nothing more.
How sandboxed preview works
The preview area is an <iframe> with a single sandbox value: allow-scripts. This is a deliberate, narrow grant of permissions. Understanding what it does — and just as importantly, what it does not do — is the security model of this tool.
What allow-scripts permits: Scripts inside your pasted HTML will execute. That means a <script> block runs at parse time, event handlers attached via addEventListener fire on user interaction, animations defined in CSS play normally, and any synchronous DOM work the script does is reflected in the preview.
What the sandbox blocks (because allow-same-origin is not set):
- The script cannot read
document.cookieof this page, because to the script the parent document is cross-origin. - The script cannot access
localStorageorsessionStorageof this page. - The script cannot read or write to the parent document via
window.parent.document. Attempting to do so throws a same-origin policy error. - Form submissions from inside the iframe go nowhere — they cannot target the parent.
- Top-level navigation from inside the iframe is blocked (it would otherwise need
allow-top-navigation). - The iframe runs in an “opaque origin” — any
fetch()requests to non-CORS endpoints will fail.
In effect, your pasted HTML executes in a hermetic environment. It can do almost anything inside the iframe but nothing outside it. This is exactly the security profile you want when pasting HTML from an unknown source: you can see what it does without trusting it.
Use cases
Debugging email templates. Email HTML uses an antiquated subset of CSS and idiosyncratic table-based layouts. Pasting a template here lets you see what most clients would render, with the obvious caveat that mail clients themselves strip and modify further.
Previewing AI-generated HTML. Modern LLMs are excellent at producing snippets of HTML and CSS. Pasting their output into a real browser context catches subtle issues — bad closing tags, missing attributes, scripts that throw on load — before you commit the code anywhere.
Testing HTML snippets without a project. When learning HTML or experimenting with a new CSS property, spinning up an entire project just to try one thing is overkill. Paste, render, iterate.
Teaching HTML and CSS. The split-pane source-and-preview layout is the canonical way to teach front-end basics: change a property, see the result.
Reviewing pull request markup. When a PR adds HTML, copying the changed file here gives a quick visual gut-check that the new markup actually renders the way the author claims.
Validating WordPress widget HTML. WordPress block and widget editors accept arbitrary HTML in HTML blocks. Pasting it here first catches breakage before you save and visit the live page.
Common HTML errors and how to spot them
Unclosed tags. A <div> without a matching </div> is the most common HTML mistake. The browser will close it for you, often in an unexpected place. In the preview here, you will see content nested or escaping its container in surprising ways.
Mismatched nesting. <p><div>...</div></p> is invalid because block elements cannot live inside paragraphs. The browser will close the <p> for you before the <div>. The preview will show the rendered result, and a peek at view source on the preview will show the browser-corrected DOM.
Missing semicolons in inline CSS. A semicolon is required between every CSS declaration. style="color:red font-size:14px" is two broken declarations; only the first might be honoured, and inconsistently.
Forgotten quotes around attribute values. <a href=https://example.com class=button> is technically valid HTML5 for single-token values, but breaks the moment any attribute value contains a space.
Self-closing tag syntax in HTML5. HTML5 ignores the trailing slash on <br /> versus <br> — both work. But <div /> does not self-close; the browser parses it as an open <div> and waits for </div>.
Script tag placement. A <script> in the <head> runs before the DOM exists, so document.getElementById(...) will return null. Put scripts at the end of <body> or add the defer attribute.
Limitations
External resources may be blocked. Cross-origin resources without CORS headers will fail to load — fonts, images, and stylesheets from arbitrary origins may not appear. Local file references (a relative path like ./image.png) will not work because the iframe has no associated file system path.
Cookies and localStorage are isolated. Your code in the preview cannot share state with the rest of your browser. This is intentional — the sandbox treats the iframe as a separate, opaque origin.
No server-side behaviour. Form actions submit nowhere. Any backend the HTML implies must be tested in a real deployment.
Some scripts behave differently than in production. Code that relies on window.parent, on cookies, or on third-party SDKs that require cookie-bearing requests will misbehave in the sandbox. That is a feature for testing untrusted code; for trusted code, deploy to a staging environment for full fidelity.
HTML safety and the sandbox
Pasting HTML from unfamiliar sources — a Stack Overflow answer, an AI-generated component, a forwarded email — is one of the more dangerous everyday acts on the modern web. If you paste it into your real site, any embedded script inherits your origin, your cookies, your storage, your everything.
The HTML Viewer flips that dynamic. The iframe is an opaque origin, isolated from your real browser context. You can paste anything and watch what it does without exposing anything. If a pasted snippet tries to read your cookies, the browser refuses. If it tries to fetch your CalcMojo session, the request fails. If it tries to redirect this entire tab, the navigation is blocked.
What you can still see is what the snippet attempts — open your browser’s DevTools and console messages from the iframe are visible, network attempts are logged, and the rendered output makes obvious any visual mischief. That is enough to make an informed decision before you take the snippet to a context where it would actually be trusted.
Frequently Asked Questions
Is my HTML stored or sent anywhere?
No. Everything happens locally in your browser. The HTML you type is rendered into a same-page sandboxed iframe; no server receives a copy. Close the tab and the source is gone.
Can I include CSS and JavaScript?
Yes. Inline <style> blocks, inline style attributes, <script> blocks, and event handlers all execute inside the sandbox. External stylesheets and scripts can also be linked, subject to the resource’s CORS policy.
Why can’t I see images from external URLs?
Images load if the image host serves them with appropriate CORS or with no CORS restrictions for image requests (most do). Some hosts block hotlinking by returning a 403 or a placeholder; those will not appear in the preview.
Is it safe to paste HTML from unknown sources?
Yes — that is one of the design goals. The preview iframe uses sandbox="allow-scripts" without allow-same-origin, which means pasted scripts cannot read your cookies, your localStorage, or any state from this page. They can do things inside their own iframe (animate, change text, attempt fetches) but cannot escape it.
Can I download my HTML?
Yes. The Download .html button saves whatever is currently in the editor as a .html file. The download is a plain HTML file you can open directly in a browser or commit to a project.
Does it support modern HTML5 features?
The preview is a standards-compliant iframe inside whatever browser you are using. Everything your browser supports — <dialog>, <details>, CSS grid, custom properties, modern JavaScript — works in the preview.
Can I preview multiple files?
The viewer is single-document. To preview HTML that links external CSS or JS files, either inline the contents into <style> and <script> blocks or host the supporting files somewhere with permissive CORS and reference them by absolute URL.
Why doesn’t my embedded video play?
Many video providers (YouTube, Vimeo) require allow-same-origin on the embedding iframe or expect specific permissions. The sandbox here is strict by design. For embed testing, use the provider’s own embed preview or deploy to a real page.
Data accurate as of: May 2026