// FREE TOOL · HTML VIEWER
HTML viewer
Open an .html file or paste the markup and see it rendered right here — in a sandboxed frame, at phone, tablet or desktop width, with anything that would misbehave listed by line number. Free, instant, no signup, and the file never leaves your browser.
Also inEnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
Drag an .html file anywhere onto this box, or pick one. It is read with FileReader, in this tab, and goes no further.
Rendering follows what you type, a third of a second behind. The notes update immediately.
A sandboxed frame with scripts allowed and no same-origin access, so the markup can run without touching this page. Pick a width to see the layout a phone or a tablet would get.
How to view an HTML file in your browser
Three steps, none of which involve uploading anything. The renderer and the notes are one script on this page, so it also works with the network off.
- Open the markup. Drag the .html file onto the box, use the file picker, or paste the markup straight in. Files are read with the browser FileReader API, so nothing is transferred anywhere.
- Look at it, then look at it narrow. The rendering appears in a sandboxed frame. Switch the frame to 360px for a phone and 768px for a tablet — the same markup, at the widths where layouts usually fall apart.
- Read the notes under it. Each note carries the line it came from: references the frame cannot reach, an image loaded over http that a secure page drops, a missing viewport that makes the narrow preview lie to you.
How this viewer renders your file
The markup goes straight into an iframe through srcdoc, with sandbox="allow-scripts" and deliberately without allow-same-origin. In practice that means three things. Your scripts run, so a page that builds itself on load actually builds itself. The frame sits in its own opaque origin, so nothing inside it can read this page, its storage or its cookies. And CSS, fonts and images fetched from public hosts load normally, so a page built on a CDN looks the way it will look for a visitor.
Two categories deliberately do not resolve, and the notes say so rather than leaving you guessing. References to files next to the original — style.css, img/hero.png — have no folder to resolve against inside the frame. References into your own filesystem never load in any browser tab; that restriction is the browser's, not ours. If the layout looks unstyled, read the notes before you go hunting through the CSS.
Looking at the page at phone width
Most viewers give you one column at whatever width the window happens to be. This one gives the frame three: 360px, roughly a phone in portrait; 768px, a small tablet; and full, whatever the column allows. The frame is a real browsing context, so media queries, container queries and flexbox wrapping all respond to the width you pick, not to your monitor.
One caveat the notes will raise for you: without <meta name="viewport" content="width=device-width, initial-scale=1">, a phone does not render at 360 CSS pixels at all. It lays the page out at around 980 and scales the result down, so text ends up tiny and your careful mobile styles never fire. The narrow preview is honest only when that tag is present — which is exactly why it is one of the things flagged under the frame.
The notes under the frame, and why a viewer usually has none
Rendering answers "does it look right". It cannot answer "will it still look right somewhere else", and that is where most of the surprises live. So every note here is tied to a line number and to one concrete consequence:
- An image over
http://is dropped by any secure page. You are looking at one right now if the example is loaded — the logo is missing above, and the note points at the line. - A path into your own disk renders on your machine and nowhere else. Inside this sandboxed frame it does not render either, which is a fair preview of everyone else's experience.
- A missing
<!DOCTYPE html>puts the browser in quirks mode, where box sizing and inherited line heights follow pre-2001 rules. The preview above is then not a preview of anything you want. - A module rather than a document — markup that begins with
importorexport default— is not renderable at all. Better to be told than to stare at a blank frame.
If your file is headed for a real address rather than a quick look, the HTML file to website page runs the same checks and follows them with the two commands that publish the folder.
What a viewer cannot do, and what to do instead
A viewer is a mirror. Nobody else can open what you are looking at: this rendering exists in your tab, has no URL, and disappears when you close it. That is the gap every tool in this category leaves — you confirm the page is right, and you are still the only person who has seen it.
What closes it is an address. Put the file in a folder as index.html, take a free handle, and deploy the folder:
$ clize claim yourname
$ clize deploy ./folder --domain yourname.clize.appThat is a live HTTPS link you can send, keep, and redeploy over. The handle is free and stays yours; you can move the same folder onto a domain you own later without touching the files. If the markup came out of a chat rather than an editor, hosting a Claude artifact covers the parts specific to that; if you want the agent that wrote the page to also publish it, that loop is Sites by Clize.
// FAQ
How do I view an HTML file without uploading it?
Open it in a viewer that reads the file locally. On this page the file is read with the browser FileReader API and rendered in a sandboxed iframe in the same tab, so the contents never reach a server. You can also just double-click the file to open it in your browser — the difference is that this page also tells you which parts of it will behave differently once the file is not on your disk.
Is it safe to paste HTML with scripts into this viewer?
The frame runs scripts on purpose, because a page that builds itself on load would otherwise show nothing. It is sandboxed without same-origin access, so code inside it cannot read this page, its storage or its cookies, and cannot navigate the tab. It can still make network requests to public hosts, exactly as it would in a normal tab, so treat untrusted markup with the same caution you would anywhere else.
Why does my CSS or image not show up in the preview?
Because the frame has no folder to resolve relative paths against. A reference like style.css or img/hero.png points at a file sitting next to your original, which the browser cannot reach from inside a srcdoc frame. Stylesheets and images loaded from an https URL do appear. The notes under the frame list every reference that could not resolve, with its line number.
Can I preview how the page looks on a phone?
Yes — set the frame to 360px for a phone or 768px for a tablet. Media queries respond to the frame width, so the layout you see is the layout at that width. One caveat: if the file has no viewport meta tag, a real phone will not use 360 CSS pixels at all, and the narrow preview will look better than the real thing. The notes flag that case.
Does this HTML viewer work offline?
Yes. Everything is one script on the page, with no network calls of its own. Once the page has loaded you can disconnect and keep opening files. Markup that pulls its own scripts or fonts from a CDN will of course render without them.
Can it open .htm, email templates or fragments?
Yes to all three. Extension does not matter — .htm and .html are read the same way. Table-based email templates render as a browser renders them, which is close to but not identical to a mail client. A fragment with no html or body tag renders too; the browser supplies the rest, and you get a note suggesting the wrapper.
How do I turn what I am previewing into a page other people can open?
Save it as index.html inside a folder, then publish that folder: clize claim yourname takes the free handle yourname.clize.app, and clize deploy ./folder --domain yourname.clize.app puts it live over HTTPS. There is no editor to move into and no export step — the bytes you previewed are the bytes that get served.
Now give it a URL someone else can open.
The rendering above lives in your tab only. Two commands turn the same file into an HTTPS address you can paste into a message — free handle, automatic certificate, redeploy as often as you like.
$ npm i -g @clize/clize && clize login $ clize claim yourname $ clize deploy ./folder --domain yourname.clize.app[ Sites by Clize → ]