HTML Viewer

The page already sitting in the editor is a status card for api.toolexe.com. Color shows up because the CSS lives in a style element. Swap in a file that points at /css/site.css and the frame falls back to the browser default type. The markup did not break but path did.

Page source and rendered frame

Load a page
Frame width

Sandbox on. Relative files do not load. Scripts still run, and their network calls still leave the browser.

Source
Rendered page
Full width, sandboxed

A pretty result here means the document is self-contained.

The sample in the editor is a status card for api.toolexe.com. Color, type, and the gaps between rows come from a style element in that same file. Nothing had to be fetched. Point the same card at /css/site.css and this frame asks toolexe.com for a stylesheet that lives on your host. The request dies. The browser paints the markup with its defaults and stays quiet about the missing file.

I would not ship a layout that only looks right in this frame.

There is no address bar for a live URL. Paste the source you already have. Fetching another site from this page fails in the browser. A preview frame is the wrong place for that request.

Treat a pretty frame as unfinished. Root-relative paths, cookies, and anything the page reads from your server are absent. If the layout depends on them, you are looking at a different page.

Same file, two rooms

Take the file you intend to publish. Read each row twice.

PieceIn this frameOn the host where the file belongs
href="/css/site.css"The request never leaves toolexe.com. No rules arrive.The file loads, if you deployed it.
src="photo.jpg"Broken image. This site has no photo.jpg.Loads when the image sits on the path you wrote.
An https addressLoads when that host sends the file to other origins. A locked asset host refuses, and the frame stays blank on that rule.Loads under the rules of your page.
A style elementPaints. This is the reliable path.Paints the same way.
action="/send"You see the fields. The sandbox keeps the post off this site, so you never see your server reply.Posts to your route, with the session and whatever token the form carries.
A script in the fileRuns, isolated from this website. It still calls out if the code says to.Runs on your origin, with your cookies in reach.

A link with target="_blank" does not open a new tab from this frame. The sandbox refuses the extra window. On your host, that attribute does what you typed.

The form row is the one people skip.

Fields that line up are the job of this page. A success banner is not. Your server never sees the click.

390 pixels is a different page

The width chips resize the frame. They do not take a screenshot.

A media query written inside the document fires, because the query measures the frame. A query that lived in /css/site.css never arrives. You switch to 390, nothing reflows, and the breakpoint you remember is sitting in the file this frame did not get.

Full width has its own trick. A card with max-width: 420px still looks like a phone layout when the chip says Full. The empty paper on either side belongs to the frame, not to a margin you authored.

Blank frame, source that looks complete? Read the link elements before you rewrite a rule. Copy the CSS into a style element, confirm the paint, then restore the link before the file ships.

When the trouble is nesting you cannot see, the HTML beautifier indents the tree. The minifier is the opposite job, for a file that is already right and only needs fewer bytes. A raw < in a paragraph belongs in the HTML encoder before the character lands in the text.

The parser rewrites the file and stays quiet

HTML is not XML.

The tree the browser builds is the page. Your keystrokes are a suggestion. The strip under the frame uses that same parser, so the heading list is the repaired tree. The editor is the raw text. When the two disagree, believe the frame about what will paint, and believe the editor about what you will save.

No doctype
The parser still invents html, head, and body. Without a doctype the document is in quirks mode. A child with height: 100% often fills the window in quirks mode. In standards mode that percentage collapses unless html and body both carry an explicit height. Add <!DOCTYPE html> as the first line before you chase a spacing bug in CSS. Check the mode before you blame the rule.
An open paragraph
A following div, heading, list, or second p closes the paragraph for you. The screen looks settled. The tree holds a closed p you never typed. That shows up later, when a selector like p + div matches a shape you did not plan, or when you wrap the block and the wrap lands in the wrong place.
Tags that cross
<b><i>word</b></i>
The word stays bold and italic. The tree does not match the keystrokes. The parser closes the i inside the b, closes the b, then emits an empty i for the stray end tag. The DOM inside the frame is that repaired tree, not the bytes in the editor.
A div dropped in a table
If the div is not inside a cell, the parser lifts it out and places it before the table. The box appears above the grid. It looks like a CSS failure. It is a parse. The broken sample on this page does this on purpose. Click it before you trust a layout bug in your own file.
A tag you invented
<price> becomes an unknown element. It displays inline. The page does not error. A screen reader gets no role from it. If you needed a price, a span or a data element with text was the honest choice.

The HTML validator lists those repairs as messages. This page shows the paint after the repair. Use the list when a layout bug will not sit still, and the frame when you need to see the boxes.

Three things the broken sample does at once

Click Broken table. Only one of the three is obvious.

The banner "Sale ends Friday" paints above the table, not inside it. The div was written between table and tr. The parser refuses to keep a div there, and moves the banner in front of the grid. People spend an hour on CSS for that. The CSS was never involved.

Both h1 elements paint large. The outline lists Notes, then Archive. The second heading reads like an h2. The frame will not make that argument. The outline will, if you look at it.

photo.jpg is a broken image. /css/site.css never arrives. The background still shifts to a pale rust, because the inline script ran. Two misses and one script, from one paste. The script is the part that worked, and the reason to keep other people's widgets out of the box.

Pixels hide the outline

A screenshot of the frame will not tell you the title was empty.

The strip lists the title, whether a doctype is present, every heading in order, images with no alt attribute, and each path the frame will not fetch. Two h1 elements both paint large. The outline puts the duplication in one column, which is easier to argue with than a rendered hero.

An omitted alt is a hole, not a tidy default. If the picture carries the words of a control, those words exist for people who see the frame and for nobody using a screen reader. The readout counts images that have no alt attribute at all. alt="" is left alone, because that empty value is how you mark a decorative image. An omitted alt and an empty alt are different decisions. Do not "fix" a count by deleting the attribute.

A fragment is still a document. Paste a lone heading and a paragraph, or press Fragment. The frame paints them. The title stays empty, because you never wrote one. The parser supplied html, head, and body around your piece. You wrote a slice of a page. The facts row is how you notice.

Leave passwords and other people's scripts out

The source stays in this browser. Toolexe does not receive the file. Close the tab and the editor is gone. Refresh does the same. There is no draft waiting on a server.

That limit is narrower than it sounds.

  • A script in the markup runs. The sandbox stops it from reading this website. The script still contacts its own server when the code tells it to. Analytics, chat widgets, and snippets copied from a page you do not control will fire.
  • API keys, session cookies, customer names, and unpublished prices do not belong in a box on a screen you share. The viewer renders them without protest.
  • Nothing here builds a link that contains your document. If someone else needs the page, send the file.

A few hundred kilobytes of markup is comfortable. A multi-megabyte export stalls the tab, because the frame rewrites the document on each pause in typing. Trim the file, or wait out the pause.

For a snippet you are still composing, the real-time HTML editor is the closer bench, with an update control aimed at drafting. This HTML viewer is the check you run on a document that already exists, when you want the frame, the width, and the list of what failed to arrive.

Copy or download before you leave. The next reload starts from the status card again.

Questions the frame keeps raising

Stylesheets, scripts, doctypes, storage, heading order, and pictures that live on your disk.

Why does the page lose its colors?

The link element still sits in the source. A root-relative or filename path asks this origin for a stylesheet that is not published here, so no rules arrive. An https address loads only when the other host sends the file to other origins. To check layout, paste the CSS into a style element, then put the link back before you ship.

Do scripts in the page run?

Yes. They run in a sandbox that cannot read this website. A script still calls its own server when the code tells it to. Leave analytics and chat widgets out.

What does a missing doctype change?

The document enters quirks mode. A child with height 100% often fills the window here and collapses on a standards-mode host, unless html and body both have an explicit height. Add <!DOCTYPE html> as the first line before you chase a spacing bug.

Does Toolexe keep the HTML?

No. The text stays in the tab. Refresh clears it. Download or copy before you leave. A screenshot of the tab is still a copy, so keep secrets out of the editor.

Why do two h1 elements both look fine?

Browsers do not police heading order in the paint. Both render large unless your CSS says otherwise. The outline under the frame lists them in document order.

The photo sits in the same folder on my computer. Why is the picture broken?

The frame has no folder. src="photo.jpg" asks toolexe.com for that name. A file on your disk is not on that path. Use an https address, or a data URL, when the picture has to appear here.

When is the real-time editor the better page?

When you are still composing a snippet and want an update control aimed at drafting. Stay here when the document already exists and you need the frame width plus the list of paths that never arrived.