Is there an HTML viewer that runs the JavaScript too?

This one does. Most online viewers render the markup and drop the scripts, which is the wrong default: the reason you are looking at the page rather than the code is usually to check that it works. The preview here is a sandboxed frame, so the page runs its own scripts in an isolated origin — it cannot touch this site or your session, and you still get the real behaviour.

Does my file get uploaded anywhere?

No. Opening a file reads it with the browser’s own file API and renders it locally; the same is true of pasting. Nothing is sent to a server unless you click publish, which is a separate, deliberate action that gives you a link.

Why does my page look right here but break when I email the file?

Because a file is not a page. Mail clients do not render an HTML attachment inline, phones frequently have no app that will open one, and managed laptops often block local files outright — the file is fine, the delivery method is not. That is the whole problem behind opening an HTML file, and the reliable fix is to send a URL instead of a file.

Can I edit the HTML here and see the change?

Yes — the left pane is a plain editor. Type in it and the preview re-renders as you go, which makes it a quick way to try a colour, a heading or a copy change without setting up an editor. It is not a full IDE and does not pretend to be: no file tree, no autocomplete, no saving to disk. Publish when you want the result to persist.

What is the difference between viewing and hosting it?

Viewing is for you, right now, in this tab. Hosting puts the page at an address other people can open, which is the part a file cannot do. Publishing here is free and needs no account, and the link lasts seven days unless you extend it — see free HTML hosting for what the hosted version gets you.

HTML viewer — paste it, see the page

Paste HTML or open a .html file and the rendered page appears next to the source, styles and scripts included. Nothing uploads until you decide to publish it.

The rendered page appears on the right, scripts and all. Nothing is uploaded until you publish.

HTML

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Invoice preview</title>
    <style>
      body { font: 15px/1.6 system-ui, sans-serif; margin: 24px; color: #18181b; }
      h1 { font-size: 20px; margin: 0 0 4px; }
      p.meta { color: #71717a; margin: 0 0 20px; }
      table { border-collapse: collapse; width: 100%; }
      th, td { text-align: left; padding: 8px 10px; border-bottom: 1px solid #e4e4e7; }
      th { background: #fafafa; font-size: 13px; text-transform: uppercase; }
      button { margin-top: 18px; padding: 9px 16px; border: 0; border-radius: 8px;
               background: #2563eb; color: #fff; font-size: 14px; cursor: pointer; }
      #total { font-weight: 600; }
    </style>
  </head>
  <body>
    <h1>Studio Meridian — March</h1>
    <p class="meta">Invoice #0142 · due 30 days</p>
    <table>
      <thead>
        <tr><th>Item</th><th>Hours</th><th>Rate</th></tr>
      </thead>
      <tbody>
        <tr><td>Design system audit</td><td>12</td><td>$120</td></tr>
        <tr><td>Component build</td><td>26</td><td>$120</td></tr>
        <tr><td>Handover session</td><td>3</td><td>$120</td></tr>
      </tbody>
    </table>
    <p id="total">Total: —</p>
    <button type="button" id="calc">Work out the total</button>
    <script>
      document.getElementById('calc').addEventListener('click', function () {
        var hours = [12, 26, 3].reduce(function (a, b) { return a + b; }, 0);
        document.getElementById('total').textContent =
          'Total: $' + (hours * 120).toLocaleString() + ' for ' + hours + ' hours';
      });
    </script>
  </body>
</html>

Preview

The preview runs the page's own CSS and JavaScript, in an isolated frame with no origin of its own. That last part is why anything using localStorage errors here and works once published — a published page gets its own origin, so its storage is real.

An .html file is the source of a web page, not the page. Open it in a text editor and you get angle brackets; open it in a browser and you get the page — which is fine until the file is an email attachment, a download on a locked-down laptop, or a block of code somebody pasted into a chat. Then there is no obvious way to just look at it.

This viewer is the missing step. Paste the markup or open the file and the right-hand pane renders it the way a browser would, with the CSS applied and the JavaScript running. The file never leaves your machine to do that: the preview is a sandboxed frame in the tab you already have open. If the page turns out to be worth showing someone, the same source publishes to a link in one more click.

What the preview does and does not do

1.
CSS applies. Inline <style>, a style= attribute and a stylesheet loaded from a CDN all work, because the frame fetches them exactly as a browser tab would.
2.
JavaScript runs. Buttons, tabs, charts and form validation behave the way they will for a reader. A viewer that quietly stripped scripts would tell you your working page is broken.
3.
Storage does not. The preview frame has no origin of its own, and localStorage throws in that situation. A page that saves state errors here and works once published, where it gets a real origin.
4.
Relative paths do not resolve. src="./logo.png" has nothing to be relative to. Anything pointing at a file next to the original on disk shows as a broken image here, and will do the same for anyone you send the file to.
5.
Nothing is uploaded. The file is read in your browser. The first network request carrying your HTML happens when you press publish.

Un ejemplo real

A recruiter is sent a candidate portfolio as portfolio.html — one self-contained file, exported from a design tool. Her work laptop opens unknown downloads in a policy-managed sandbox that refuses local files, so double-clicking does nothing useful and the preview pane in her mail client shows the first two hundred characters of markup.

She opens this page, clicks Open .html file, and picks the download. The portfolio renders in the right pane: the grid of project cards, the web font, the hover states, and the filter buttons that actually filter because the file’s own script is running. No install, no policy exception, nothing sent anywhere — the file was read by the browser tab she already had open.

Two of her colleagues need to see it before the interview. Rather than forwarding a file that will fail on their machines the same way it failed on hers, she clicks publish and pastes the link into the hiring channel. They open it on a phone and a Windows desktop and see the same page she did.

Preguntas sobre html viewer online

Conserva tus enlaces para siempre

Los enlaces gratuitos duran 7 días con una cuenta gratuita. Con un plan de pago, cada página que publiques se queda online de forma permanente.

Ver precios

Casos de uso relacionados

What the preview does and does not do

CSS applies. Inline <style>, a style= attribute and a stylesheet loaded from a CDN all work, because the frame fetches them exactly as a browser tab would.

JavaScript runs. Buttons, tabs, charts and form validation behave the way they will for a reader. A viewer that quietly stripped scripts would tell you your working page is broken.

Storage does not. The preview frame has no origin of its own, and localStorage throws in that situation. A page that saves state errors here and works once published, where it gets a real origin.

Relative paths do not resolve. src="./logo.png" has nothing to be relative to. Anything pointing at a file next to the original on disk shows as a broken image here, and will do the same for anyone you send the file to.

Nothing is uploaded. The file is read in your browser. The first network request carrying your HTML happens when you press publish.

Un ejemplo real