HTML Viewer

Paste HTML source; it is previewed live and instantly in an isolated, sandboxed frame. The content is processed entirely in your browser and is not sent to a server. For safety, scripts are not executed — only HTML and CSS are rendered.

Last updated:

HTML Source
Paste your HTML markup. The preview updates as you type.

Live Preview

The preview loads inside a sandboxed iframe: scripts, forms and access to the parent page are blocked. Only HTML and CSS are evaluated.

When this viewer earns its keep

Iterating on email templates

Edit, send a test, wait for the inbox, open, squint: minutes per lap. Pasting the markup here cuts the lap to seconds, and the worked example below shows how far the simulation carries.

Vetting snippets before they touch a codebase

Components copied from the web arrive with stray wrappers and sometimes scripts you did not order. Inspecting them in a frame that cannot execute anything keeps the cleanup away from live pages.

Sketching layout ideas

Settling a flex-versus-grid question does not require a project scaffold or a dev server. Two minutes here answers it; the permanent version goes into the repo.

Worked example: an email template, minus the send loop

Email HTML is its own dialect: nested tables and inline styles, the way 1999 never ended. That dialect happens to preview here unusually well.

  1. Paste a table-based template: <table> rows, <td> cells, every style declared inline.
  2. The preview renders it in an isolated document, so none of this site's CSS bleeds in; what you see is the markup's own truth.
  3. Change an inline style and the preview updates as you type: the edit loop is seconds, not a send-and-wait cycle.
  4. Images with absolute URLs load where policies permit; relative paths resolve to nothing because the frame has no base URL.
  5. Scripts stay off by design, which mirrors real mail clients: they refuse JavaScript too.

For email work the no-script sandbox is a feature twice over: it is safe, and it is realistic. What it does not simulate is the rendering quirks of individual clients, Outlook's engine above all. Use the preview to converge fast, then spend the expensive real-client test on the final candidate only.

Four mistakes worth avoiding

Expecting a SPA fragment to render

A component whose markup is an empty mounting div builds its content in JavaScript, and JavaScript deliberately does not run here. The empty preview is the design working, not failing.

Relying on relative asset paths

There is no base URL in the preview document, so ./style.css and ../img/logo.png cannot resolve. Inline the styles, use absolute image URLs, and the mysterious blank boxes disappear.

Reading one engine as a compatibility matrix

The preview shows your own browser's interpretation and nothing else. Other engines and email clients may disagree with it; treat the preview as a fast iteration surface, not the final word.

Declaring pasted HTML clean because nothing happened

Nothing happened because the sandbox made sure of it. The same snippet pasted into a context that executes scripts keeps every hazard it arrived with; strip script tags and event-handler attributes before promoting markup anywhere trusted.

Tools commonly used alongside this one

  • HTML / Entity Encoder-Decoder Encode text to HTML entities or decode it back. Escape special characters to prevent XSS; in the browser, no signup.
  • JWT Decoder Decode the header and payload of a JSON Web Token, inspect the standard claims and expiry. The token never leaves your browser.
  • Kubernetes Resource Budget Calculator Estimate how many nodes you need, your packing efficiency, and the projected monthly cost from pod requests and node size.
  • UUID Generator Generate cryptographically secure UUID v4 and time-ordered v7. Bulk generation and format options.
  • Base64 Encoder-Decoder Encode text to Base64 or decode it back. Standard and URL-safe (base64url) variants; UTF-8 aware, in the browser.

Frequently Asked Questions

Is the HTML I paste sent to a server?

No. The HTML is previewed entirely in your browser by writing it to an iframe's srcdoc; it is not sent to a server and is not stored anywhere. When you close the page, no trace remains.

Why does JavaScript not run in the preview?

The preview loads in an iframe with a restrictive sandbox attribute. This deliberately blocks running scripts, submitting forms and accessing the parent page. That makes pasting unknown HTML safe — the tool is a viewer, not a code runner.

What is this tool useful for?

For quickly seeing email templates, HTML snippets, CSS layouts and static components. You edit the markup and see the result instantly, without setting up a full project.

Are external CSS files and images loaded?

Styles and images given with absolute (https://) URLs load as far as the browser's and page's security policies allow. Relative paths (./style.css) do not work because the preview has no base address — inlining styles in a <style> block is the most reliable approach.

Why is the preview always on a white background?

The preview frame is an isolated document, unaffected by the site's light/dark theme. So your HTML appears with its own styles and the browser defaults (white background) — the result closest to how it will look in real deployment.