HTML Viewer & Live Editor

An HTML viewer lets you see what a piece of markup actually looks like without saving a file, opening it in a browser and refreshing every time you change something. Our free HTML Viewer and Live Editor puts a code editor with line numbers on the left and a live preview on the right that updates as you type. The preview runs in a sandboxed frame, so scripts in the code you paste cannot reach this site's cookies or storage, and you can switch JavaScript off entirely with one toggle. Check how a snippet looks at mobile, tablet and desktop widths, test an HTML email before you send it, then download the result as an .html file. Everything happens in your browser, so nothing you paste is uploaded.

How to use the HTML viewer

1. 1 Paste or type your HTMLDrop a full page, an email template or a small snippet into the editor on the left. Line numbers make it easy to find the part you want to change. Use Load sample if you just want to try the tool.
2. 2 Watch the live previewThe preview on the right redraws a moment after you stop typing, so you can tweak a colour, a heading or a table and see the effect straight away.
3. 3 Choose JavaScript on or offLeave scripts running to test interactive snippets, or switch JavaScript off to see the page as static markup and styles only. Turning it off is the safest choice for code you do not trust.
4. 4 Check different screen widthsSwitch the preview between mobile at 375 pixels, tablet at 768 pixels and full desktop width to see how your layout and media queries respond.
5. 5 Download or copy your workSave the code as an .html file to open later or hand to a colleague, or copy it back into your CMS, email platform or code editor.

What an HTML viewer is for

HTML is the markup behind every web page and most marketing emails. Reading raw tags tells you what the structure is meant to be, but it is surprisingly hard to picture the finished result from the code alone, especially once inline styles, tables and classes pile up. A viewer closes that gap by rendering the markup exactly as a browser would, right next to the code that produces it.

People use it for all sorts of everyday jobs. A marketing assistant in Leicester might paste in the HTML of a newsletter exported from an email platform to check that the layout has not broken. A small business owner might preview a snippet a developer sent over before adding it to a WordPress page. A student learning web development can experiment with tags and styles and see the effect immediately, without setting up a code editor and local files. Developers use it to isolate a bug: copy the smallest piece of markup that shows the problem, paste it in, and change one thing at a time until the cause becomes obvious.

Because the editor and preview sit side by side, you get a fast feedback loop. Change a padding value, a font size or a colour and the preview updates within a moment. That makes it a handy scratchpad for trying ideas that you would otherwise test by editing a live site, which is never a good idea.

How the sandboxed preview keeps you safe

Pasting unknown HTML into a page can be risky, because HTML can carry JavaScript and JavaScript can do a lot if it runs with the wrong permissions. Our preview is rendered inside an iframe using the srcdoc attribute, with the sandbox attribute set to allow scripts but not same-origin access. In plain terms, scripts in your code can run, but the browser treats the preview as if it came from a separate, anonymous origin.

That isolation matters. Code in the preview cannot read cookies or local storage belonging to makeitflow.si, cannot reach into the editor or the rest of the page, and cannot pretend to be this site. The sandbox also blocks forms from submitting and stops pop-up windows from opening, so a snippet cannot quietly send data somewhere or bombard you with new tabs.

If you want to be even more cautious, switch JavaScript off. The preview then renders HTML and CSS only, with no scripts at all. This is the right setting for checking an email from an unknown sender, a suspicious attachment saved as HTML, or code copied from a forum. Remember that the sandbox protects this site and your browser session; it does not make the content itself trustworthy, so never type passwords or personal details into anything shown in the preview.

Testing responsive layouts at different widths

Most visits to UK websites now come from phones, so a layout that only looks right on a wide monitor is a problem. The width buttons let you resize the preview frame to common breakpoints without dragging your browser window around or opening developer tools.

• Mobile, 375 pixels: close to the CSS width of many current smartphones in portrait. Check that text wraps, images shrink and nothing forces sideways scrolling.
• Tablet, 768 pixels: a common tablet width in portrait and a popular breakpoint in CSS frameworks. Look at how columns stack or sit side by side.
• Desktop, full width: the preview fills the available space so you can see the layout as it would appear on a laptop or monitor.
• Media queries respond to the width of the preview frame, not your whole screen, so a rule written for screens under 600 pixels will switch on in the mobile view just as it would on a real phone.

Previewing HTML emails and snippets

HTML emails are one of the most common reasons to reach for a viewer. Email templates are often built with nested tables and inline styles, and a single missing closing tag can push a whole column out of place. Pasting the template here gives you a quick visual check of structure, images, buttons and spacing before you send a test to real inboxes.

Be clear about what this check can and cannot tell you. Our preview uses your web browser's rendering engine. Email clients do not behave like browsers: Outlook on Windows has long used a Word-based engine with limited CSS support, Gmail strips or rewrites some styles, and Apple Mail is more forgiving than most. A layout that looks perfect here can still break in a particular client, so treat the viewer as a first pass and always send test emails to the main clients your audience uses.

The same applies to snippets meant for a CMS. Page builders and themes add their own styles, so a block that looks right in isolation may pick up different fonts, margins or colours once it is placed on the live page. The viewer shows you the snippet on its own, which is exactly what you want when you are trying to find out whether a problem comes from the snippet or from the surrounding site.

Images, links and external files

The preview has no folder of files behind it, so relative paths cannot be resolved. An image written as images/logo.png or a stylesheet linked as css/style.css means nothing on its own, because the viewer does not know which website those paths belong to. The result is a broken image icon or unstyled text.

There are two easy fixes. Either change the paths to full addresses beginning with https://, or add a base tag inside the head of your document pointing at the site the files live on, such as a base element with an href of https://www.example.co.uk/. Every relative link and image path will then be resolved against that address. Remove the base tag again before using the code elsewhere if you do not need it.

Files loaded from a full URL, including stylesheets and scripts from public CDNs such as a font service or a CSS framework, do load in the preview, as long as the server allows it and JavaScript is switched on where scripts are concerned. Links inside the preview are best treated as visual only; the sandbox restricts navigation, so check where links point by reading the href in the code rather than clicking them.

Privacy and what happens to your code

The editor, the preview and the download all run in JavaScript inside your browser. Your HTML is not sent to our server, stored or logged, which makes the tool suitable for unreleased landing pages, client templates and internal documents. If your code loads images or files from other websites, your browser will request those files from their servers in the usual way, just as it would if you opened the page normally.

Nothing is saved between visits, so refreshing or closing the tab clears the editor. Download your work as an .html file, or copy it into your own project, before you leave the page.

Examples you can copy

<!DOCTYPE html>
<html lang="en-GB">
<head>
  <meta charset="utf-8">
  <base href="https://www.example.co.uk/">
</head>
<body>
  <img src="images/logo.png" alt="Company logo">
  <a href="contact/">Contact us</a>
</body>
</html>

<style>
  .cards { display: grid; grid-template-columns: repeat(3, 1fr); gap: 16px; }
</style>
<div class="cards">
  <div>Plumbing</div>
  <div>Heating</div>
  <div>Electrics</div>
</div>

Add a media query for max-width: 600px that sets
grid-template-columns: 1fr, then switch to the mobile view.

Common mistakes to avoid

Frequently asked questions