What does an HTML viewer do?
An HTML viewer renders markup the way a browser would, and then offers three other readings of the same input: the heading outline, the plain text with a word count, and the raw source. The rendered view is a real layout produced by the browser's own engine inside an iframe, so what you see is what the markup does rather than an approximation of it.
The frame is sandboxed with no permissions at all, which is what makes it safe to paste markup you did not write. No script runs, no form submits, no link navigates and the content sits in an origin that cannot reach this page's cookies or storage. The trade-off is real and worth stating: a page that builds its content with JavaScript will appear empty here, because the script that would fill it in is not allowed to run.
The outline view is the part that answers a question rather than merely displaying one. Headings are how a screen reader announces a document and how a crawler infers its structure, and a page that jumps from h1 straight to h4, or forgets the h1 entirely, has a defect that is invisible in the rendered view and obvious in the list. The plain-text view strips tags and script, counts the words, and shows how much of the page is actually content.
How to view and inspect HTML
- Paste a fragment or a whole document into the box. The preview renders as you type.
- Use Rendered preview to see it laid out. Set the frame width to a narrow value to check how it behaves at phone size.
- Switch to Outline to read the heading structure. A missing h1 or a skipped level shows up immediately.
- Switch to Plain text for the words a visitor would actually read, with counts of words, links and images.
- Switch to Source to read exactly what is being rendered, and copy it if you want the block elsewhere.
- Check the amber note if it appears: it means the parser had to correct something, so the preview is its best reading of the markup.
HTML Viewer limits and rules
| Item | Limit |
|---|---|
| Input | A fragment or a complete document, pasted as text |
| Rendering | A real iframe, laid out by the browser's own engine |
| Sandbox | Empty sandbox value: no scripts, forms, navigation, plugins or same-origin access |
| Remote resources | Not fetched, so external stylesheets, images and fonts do not load |
| Outline | h1 to h6 in document order, with the level shown |
| Text view | Tags, scripts and styles removed; word, link and image counts |
| Frame width | Adjustable from 200 to 2000 pixels for a responsive check |
| Not offered | No DOM inspector, no computed styles, no console output |
When to use it
- Checking that an email or CMS template produces the heading structure you intended before publishing.
- Reading a fragment of markup from a support ticket to see what it actually renders as.
- Extracting the text from a block of HTML without opening an editor.
- Checking a page's heading outline for an accessibility or SEO review, where levels and order matter.
- Seeing how a table or a form looks at phone width without deploying anything.
Is it private?
Nothing is sent anywhere and nothing is stored. The markup is rendered in a sandboxed frame on your own machine, and a script inside it cannot run, cannot read this site's storage and cannot make a request on your behalf. Closing the tab discards the input.
Frequently asked questions
Because nothing is fetched. A stylesheet, an image or a font referenced by an absolute URL, whether from a CDN or from your own site, is deliberately not loaded — that is what keeps the viewer offline and harmless. The markup renders with the browser's default styles, which is enough to judge structure and content but not enough to judge design. Inline styles and a style element inside the pasted markup do apply, since they travel with it.
Because it builds itself with JavaScript and the sandbox forbids scripts. A client-rendered application sends markup that is mostly an empty container, and the visible content exists only after its scripts run. The sandbox is the whole point of the tool: allowing script would mean a pasted page could read cookies, make requests or navigate you elsewhere. The source and outline views still work on such markup, and that is usually what you wanted to inspect anyway.
It lists every heading in document order with its level, which is how a screen-reader user and a search crawler navigate a page. The two defects it exposes are a missing h1 or several of them, and a skipped level such as an h1 followed by an h4 — the latter usually means a heading was chosen for its appearance rather than its place in the structure, which is exactly the confusion the levels exist to prevent. Fixing the order is often easier than it looks; the styling can stay as it is.
Close enough for a check but not identical. The text view removes script, style, noscript and template elements, then reads what is left, which means comments are dropped, hidden text is still counted if it was hidden by a stylesheet rather than an attribute, and alt text on images is not included. Its real use is comparative: if a page of six hundred words reports sixty, most of the content is coming from somewhere other than the markup you pasted.
You can see how a form is laid out and structured, but you cannot submit it — the sandbox blocks form submission deliberately, so pressing a button does nothing. That is the right behaviour for pasting markup from an unknown source, since a form action could otherwise post data somewhere you did not intend. To test a form's logic you need it served from a page you control; to check its labels, fields and structure, the preview is enough.
It renders it the way a browser would, which means it applies the same error-recovery rules: an unclosed tag is closed implicitly, a stray element is hoisted to where the parser thinks it belongs, and a table without rows may be dropped entirely. That is genuinely useful, since it shows what a visitor would see. Where the parser had to intervene, a note appears above the preview, and it is worth taking seriously — other parsers, including the ones used for email clients, apply slightly different rules.
Related tools
Written and maintained by Md. Nur Hossain Repon.