Logo

MonoCalc

/

Online HTML Editor

Programming

Source and visual

0 lines · 0 B

Live preview

Scripts disabled

Full width · Desktop

Nothing to render yet

Write some HTML, drop a file onto the editor, or start from one of the templates above.

Re-indent the document so it can be read and reviewed.

Everything here runs in your browser. No markup is uploaded, logged or sent anywhere.

About This Tool

Online HTML Editor - Write, Preview and Clean Up Markup in Your Browser

An online HTML editor removes the ceremony from testing a piece of markup. Instead of creating a file, saving it, starting a local server and switching to a browser, you paste a snippet on the left and watch it render on the right. This editor pairs a line-numbered code surface with a sandboxed live preview, a visual WYSIWYG mode, and a set of transformations - beautify, minify, sanitize, strip tags and entity escaping - that turn messy real-world markup into something you can actually ship.

How the live preview works

Your document is assembled into a complete HTML page - doctype, <head>, your inline CSS, your markup - and handed to an <iframe> through the srcdoc attribute. Rendering restarts roughly 300 ms after you stop typing, which is long enough to keep typing smooth on a large document and short enough to feel instant. The frame is sandboxed, so the previewed page has no route back into the editor.

Scripts are opt-in, and the sandbox stays real
The preview frame is never granted allow-same-origin. A frame that holds both allow-same-origin and allow-scripts can reach straight into the page that embeds it, which makes the sandbox decorative. Turning on Allow scripts adds allow-scripts and nothing else.

Beautify, minify and the difference between them

Beautifying re-indents machine-generated or minified markup into readable, correctly nested HTML at the indent style, indent size and wrap length you choose. It only moves whitespace: comments, attributes and text survive untouched. Minifying goes the other way, collapsing whitespace a browser would not paint, dropping comments, collapsing boolean attributes and optionally removing attribute quotes, then reporting the saving as both bytes and a percentage. Whitespace inside <pre>, <textarea>, <script> and <style> is byte-significant and is never collapsed.

Cleaning markup pasted from Word or Google Docs

Content pasted out of a word processor arrives wrapped in class="MsoNormal", <o:p> tags, inline style declarations and <font> elements. The Sanitize pass rebuilds the document from a whitelist of semantic tags - headings, paragraphs, lists, links, tables, emphasis - rewrites <b> to <strong> and <i> to <em>, and keeps only the href, src, alt and title attributes. Anything that is not on the list is unwrapped rather than deleted, so no text is ever lost.

Escaping is not sanitising
Escaping converts < and & into entities so a snippet can be displayed as code. Sanitising removes the parts of a document that are unsafe or meaningless. Escaping a hostile string makes it printable; it does not make it safe to re-insert as markup, and sanitising is what you want before storing user content.

What the statistics and diagnostics tell you

Every count comes from a real tokenizer rather than a regular expression, so a <div> written inside a JavaScript string is not miscounted as an element. Byte size is measured with UTF-8 encoding, which is why an emoji costs four bytes rather than one character. The nesting depth readout is a good early warning: markup nested past ten levels is usually a sign of wrapper <div> soup that will make CSS specificity painful later, and the tag frequency chart makes the same point visually - a document that is 60% <div> is not a semantic document.

The diagnostics panel is advisory and never blocks anything. It reports unclosed tags with the line where they opened, deprecated elements such as <center> and <font> with the CSS property to reach for instead, and accessibility hints: images with no alt, form controls with no label, a missing lang, empty headings and heading levels that jump from h1 straight to h4.

Block, inline and void elements

Three distinctions explain most surprises in the preview. Block elements - div, p, section, li - start on a new line and fill the available width. Inline elements - span, a, strong - flow inside a line, which is why two adjacent inline elements with no whitespace between them render as one unbroken word. Void elements - br, img, hr, input, meta - never take a closing tag, and writing one is a parse error the browser silently recovers from.

Privacy

Parsing, rendering, formatting and every export happen inside your own browser tab. Nothing is uploaded, logged or transmitted, which matters for HTML in particular: page source routinely carries staging URLs, customer names inside a rendered table, unreleased copy and API keys tucked into data- attributes.

Frequently Asked Questions

Is the Online HTML Editor free?

Yes, Online HTML Editor is totally free :)

Can I use the Online HTML Editor offline?

Yes, you can install the webapp as PWA.

Is it safe to use Online HTML Editor?

Yes, any data related to Online HTML Editor only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.

How does this online HTML editor work?

You write or paste markup on the left and it is rendered on the right inside a sandboxed `iframe` fed through `srcdoc`, refreshed about 300 ms after you stop typing. The same source is tokenised into a node tree in your browser, which is where the element counts, nesting depth, tag-frequency table and the unclosed-tag, accessibility and deprecated-element warnings all come from. Beautify, minify, sanitise, strip-tags and entity escaping are separate passes over that tree, so each one reports exactly what it changed.

Can the markup I preview run scripts or reach the rest of the page?

Not unless you ask it to. The preview frame is fully sandboxed, so scripts, forms and navigation are all blocked by default and the badge above the frame always tells you which state you are in. Turning `Allow scripts` on adds the `allow-scripts` permission and nothing else - the frame is never given `allow-same-origin`, because a frame holding both permissions can reach straight back into the page that embeds it, which would make the sandbox decorative.

Is my HTML uploaded anywhere?

No. Parsing, rendering, formatting and every export happen inside your own tab, with no server round-trip. That matters for page source in particular, because real markup routinely carries customer names in a rendered table, staging URLs, API keys in `data-` attributes and unreleased copy.

What is the difference between sanitising, escaping and stripping tags?

Sanitising keeps the document but throws away everything that is not semantic: it whitelists tags such as `p`, `h2`, `ul` and `a`, rewrites `<b>` to `<strong>`, and drops every attribute except `href`, `src`, `alt` and `title` - which is what turns pasted Word or Google Docs markup back into clean HTML. Escaping keeps every character but converts `<`, `>`, `&`, `"` and `'` into entities so the snippet can be displayed as code inside another page. Stripping tags throws the markup away and keeps only the readable text.

Will editing in Visual mode change my source?

Yes, and deliberately so - that is the point of a two-way editor. The visual surface understands a semantic subset (headings, paragraphs, lists, links, emphasis, quotes, code and rules), so if your document contains anything outside it, such as a table, an image or a form, the editor warns you by name before you type. Nothing is rewritten until you actually make an edit there, so you can look without committing, and Code mode keeps its own undo history.

How accurate are the statistics and warnings?

The counts come from the same tolerant parser a browser-style tree builder uses, so they describe how the markup actually parses rather than what a regular expression guessed - a `<div>` written inside a JavaScript string is not counted as an element. Byte size is measured with UTF-8 encoding, so an emoji costs four bytes rather than one character. Every warning is advisory: nothing blocks rendering, copying or downloading.