DEV Community: Tusing1

How to Preview and Debug HTML Online Without Installing Anything

Tusing1 — Fri, 09 Oct 2026 11:37:43 +0000

You do not always need a full local development environment to answer the first question about a webpage: why is this HTML not working?

A browser-based editor can be enough to reproduce a problem, reduce it to a small example and test a correction. This is especially useful on a borrowed computer, a phone or a machine where installing software is not practical.

I maintain HTML Online Viewer, a browser workspace for editing and previewing HTML side by side. Building and testing it helped me turn my own debugging routine into the workflow below. This article was prepared with AI assistance, then reviewed and edited against working examples.

Start with one portable HTML file

When a problem involves HTML, CSS and a little JavaScript, put all three into one document first. That removes file paths, build tools and dependency setup from the investigation.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Button test</title>
    <style>
      button {
        padding: 0.75rem 1rem;
      }
    </style>
  </head>
  <body>
    <button id="greet">Show greeting</button>
    <p id="message"></p>

    <script>
      document.querySelector('#greet').addEventListener('click', () => {
        document.querySelector('#message').textContent = 'Hello!';
      });
    </script>
  </body>
</html>

If this self-contained version works, the original bug may be in a missing file, an incorrect path, a build step or the order in which scripts load. If it still fails, the problem is now small enough to inspect directly.

Use the smallest reproducible example

Consider this deliberately broken page:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Reading list</title>
    <style>
      .card { border: 1px solid #bbb; padding: 1rem; }
      .card button { background: navy; color: white; }
    </style>
  </head>
  <body>
    <main class="card">
      <h1>Reading list</h1>
      <p id="status">No book selected<p>
      <button id="choose">Choose a book</button>
    </main>

    <script>
      document.querySelector('#chosen').addEventListener('click', () => {
        document.querySelector('#status').textContent = 'HTML for Everyone';
      });
    </script>
  </body>
</html>

It contains two separate mistakes:

The paragraph ends with another opening <p> instead of </p>.
JavaScript searches for #chosen, but the button's ID is choose.

The browser may repair the paragraph automatically, so the page can look almost correct. The button still fails because document.querySelector('#chosen') returns null.

Do not keep adding code while debugging. Remove unrelated markup until the failure is easy to reproduce. A ten-line example that still fails is more useful than a thousand-line page that fails for several reasons.

Check HTML structure before styling

Browsers are forgiving. That is helpful for visitors, but it can hide mistakes from developers.

Before changing CSS, check:

opening and closing tags;
accidentally nested forms, links or buttons;
duplicate IDs;
whether content belongs inside <head> or <body>;
whether important elements are actually present;
whether quoted attribute values are closed.

Formatting the document can make nesting errors easier to see. Validation can point out invalid structure, but treat its messages as evidence to investigate rather than instructions to apply blindly.

The paragraph above should be:

<p id="status">No book selected</p>

Test selectors one boundary at a time

When JavaScript does nothing, verify the boundary between the HTML and the script.

const button = document.querySelector('#choose');
const status = document.querySelector('#status');

console.log({ button, status });

If either value is null, fix the selector or markup before inspecting the rest of the function. Then add the interaction:

button.addEventListener('click', () => {
  status.textContent = 'HTML for Everyone';
});

Also confirm that the script runs after the required HTML exists. A script at the end of <body> works for this small example. A script in <head> should normally use defer or deliberately wait for the document.

Read the first useful error

One failure can produce several console messages. Start with the earliest message that points to your own code.

For the broken example, a browser may report an error similar to:

Cannot read properties of null (reading 'addEventListener')

Translate it into plain language:

addEventListener was called;
the value before it was null;
the selector did not find an element.

Fix that cause, reload and check again. Later messages may disappear automatically.

Do not paste secrets, private source code or customer data into a third-party editor or an AI debugging prompt. Reduce the bug with invented data instead.

Check missing assets and relative paths

An online preview has its own document location. Relative paths from a project on your computer may not exist there:

<img src="../images/team.jpg" alt="Our team">
<script src="./scripts/app.js"></script>

For a portable test, either:

include CSS and JavaScript directly in the HTML;
use a public test asset that you control;
import the related files if the editor supports them; or
replace the asset temporarily and test the layout's missing-image state.

If the portable version works, restore the real project paths only after returning to the project's actual folder structure.

Test phone, tablet and desktop widths

A page can be correct at one width and unusable at another. Check at least a narrow phone, a tablet and a desktop layout.

Look for:

horizontal scrolling;
text or controls extending outside a card;
fixed widths wider than the viewport;
images without max-width: 100%;
buttons that are too small to tap;
long URLs or code that refuse to wrap.

A useful baseline is:

* {
  box-sizing: border-box;
}

img {
  max-width: 100%;
  height: auto;
}

.card {
  width: min(100% - 2rem, 44rem);
  margin-inline: auto;
}

Do not shrink everything until it fits. Find the element causing the overflow and correct its layout rule.

Preserve the exact test case

Once the fix works, export or save the self-contained HTML file. Give it a name that describes the behaviour, such as:

button-selector-fixed.html

That file becomes a regression example. If the same feature breaks later, you already have a known-good version for comparison.

Import and export are also useful when a long document should not be copied through the clipboard. Confirm that an exported file opens correctly in a normal browser before calling the test complete.

Know when an online HTML preview is not enough

A browser-only editor is useful for client-side HTML, CSS and JavaScript. It is not a replacement for every development environment.

Move to the appropriate local or hosted environment when the example needs:

Node.js or another server runtime;
PHP, Python, Java or database code;
private packages or environment variables;
authentication callbacks;
unrestricted cross-origin requests;
a framework build pipeline;
filesystem or operating-system access.

The preview should help identify which boundary the problem crosses. It should not pretend to execute a backend that does not exist.

A repeatable browser-only debugging loop

Use this short sequence:

Copy the failing feature into one self-contained HTML file.
Remove unrelated code while keeping the failure reproducible.
Format and inspect the document structure.
Verify selectors and required elements.
Read the first useful error from your own code.
Test missing assets and narrow screens.
Make one small change and preview again.
Export the known-good example.
Retest the fix inside the real project.

The corrected example is:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Reading list</title>
    <style>
      * { box-sizing: border-box; }
      .card {
        width: min(100% - 2rem, 44rem);
        margin: 2rem auto;
        border: 1px solid #bbb;
        padding: 1rem;
      }
      .card button { background: navy; color: white; padding: 0.75rem 1rem; }
    </style>
  </head>
  <body>
    <main class="card">
      <h1>Reading list</h1>
      <p id="status">No book selected</p>
      <button id="choose" type="button">Choose a book</button>
    </main>

    <script>
      const button = document.querySelector('#choose');
      const status = document.querySelector('#status');

      button.addEventListener('click', () => {
        status.textContent = 'HTML for Everyone';
      });
    </script>
  </body>
</html>

You can paste this example into any standards-based HTML preview. If you want to try the workflow in the tool I maintain, open HTML Online Viewer, change one selector deliberately and observe the failure before applying the fix.

What is the first thing you check when a webpage renders correctly but its JavaScript does nothing?

How I Review AI-Generated HTML Before Publishing It

Tusing1 — Tue, 29 Sep 2026 03:58:09 +0000

AI can produce a complete-looking webpage in seconds. That speed is useful, but a page that looks finished may still contain broken structure, inaccessible images, unsafe links or code you did not intend to run.

I built HTML Online Viewer because I wanted a quick way to inspect HTML and see its result side by side. While adding an AI Coding Lab to the project, I turned my own review routine into the checklist below. This article was written with AI assistance and then edited, verified and tested by me.

The goal is not to distrust every generated line. It is to make review small enough that you will actually do it.

A deliberately imperfect example

Here is a short page containing three problems that are easy to miss when scanning a larger AI response:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Community Health Day</title>
  </head>
  <body>
    <main>
      <h1>Community Health Day</h1>
      <p>Free health checks at the town hall.<p>
      <img src="health-team.jpg">
      <a href="javascript:alert('Hello')">Reserve a place</a>
    </main>
  </body>
</html>

The page may still render, but it is not ready to publish:

The paragraph has another opening <p> where its closing </p> should be.
The image has no alt description.
The link executes JavaScript instead of navigating to a clear destination.

Step 1: keep the first preview isolated

Do not paste unfamiliar HTML into an important production page first. Open it in a separate preview whose frame is sandboxed. This limits what the preview can do to the surrounding application.

A sandbox is a safety boundary, not a guarantee. If the code depends on third-party scripts, forms, logins or private data, read those parts before enabling them. Never paste passwords, API keys or customer information into code you did not fully review.

In HTML Online Viewer, paste the document into the editor and use the live preview. The tool runs the preview in an isolated frame and keeps ordinary editing in your browser.

Step 2: check document structure before styling

Start at the top and confirm the page has the essential document pieces:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>A useful, specific page title</title>
  </head>
  <body>
    <!-- Visible page content -->
  </body>
</html>

Then follow opening and closing tags. Indentation helps reveal whether an element closes in the place you expect. A formatter is useful here, but do not assume that formatting has repaired the meaning of the document.

For the broken example, change:

<p>Free health checks at the town hall.<p>

to:

<p>Free health checks at the town hall.</p>

Step 3: inspect every URL and executable section

Search for these strings:

<script
javascript:
onclick=
onerror=
iframe
form
fetch(
localStorage

None is automatically malicious. Each one simply deserves an explanation.

Ask:

Which domain does this script, image, form or frame contact?
Does a click run code that the visible label does not explain?
Does the page read or store information?
Would the feature still work with the third-party code removed?

Replace the example’s JavaScript link with a real route:

<a href="/reserve">Reserve a place</a>

If there is no reservation page yet, use an ordinary button only when JavaScript will provide a clearly defined action. Do not leave a link that pretends to navigate.

Step 4: perform a keyboard and meaning check

AI-generated pages often favour visual appearance over semantics. Before judging colours or spacing, check the reading structure:

There should normally be one clear <h1> for the page.
Heading levels should describe sections, not merely create large text.
Interactive actions should use links or buttons, not clickable <div> elements.
Form controls need visible labels.
Images need useful alt text when they communicate meaning.
Decorative images should use alt="" so a screen reader can skip them.
Focus should remain visible when you move with the Tab key.

For the example, add an alternative description that conveys the image’s purpose:

<img src="health-team.jpg" alt="Nurses welcoming visitors at a community health event">

Then use only the keyboard to move through every control. Confirm that focus order matches the visual order and that every action can be reached and understood.

Step 5: test narrow screens, missing assets and long content

A polished desktop preview is not enough. Check at least:

a narrow phone width;
a tablet width;
a wide desktop width;
200% browser zoom;
a deliberately long heading;
an unavailable image;
a slow or blocked external resource.

Look for horizontal scrolling, clipped buttons, overlapping text and controls that become too small to tap. The browser console may also reveal a missing image or script that the visible design hides.

Step 6: validate behaviour, not just appearance

Open every link. Submit every form with valid and invalid input. Trigger empty states. Reload the page. If a feature stores data, explain where that data goes and test what happens when storage is unavailable.

For generated JavaScript, read the code path that runs before you press the button. A pleasant label such as “Generate report” does not tell you whether the code downloads a file, sends data to a service or both.

Step 7: make one controlled fix at a time

Large AI rewrites can solve one problem while introducing another. Prefer a short loop:

Describe one observable problem.
Change the smallest relevant section.
Preview again.
Repeat the same keyboard, mobile and error checks.
Save a working version before the next change.

The corrected example becomes:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Community Health Day</title>
  </head>
  <body>
    <main>
      <h1>Community Health Day</h1>
      <p>Free health checks at the town hall.</p>
      <img
        src="health-team.jpg"
        alt="Nurses welcoming visitors at a community health event"
      >
      <a href="/reserve">Reserve a place</a>
    </main>
  </body>
</html>

My pre-publish checklist

I use this short list before an AI-assisted page leaves a preview:

[ ] I understand every external URL and script.
[ ] The document has a doctype, language, charset, viewport and useful title.
[ ] Opening and closing tags match.
[ ] The heading order communicates the page structure.
[ ] Images have appropriate alternative text.
[ ] Links and buttons describe what they do.
[ ] Keyboard focus reaches every interactive control.
[ ] Phone, tablet, desktop and zoom layouts do not overflow.
[ ] Empty, invalid and missing-asset states make sense.
[ ] No secrets or private data are embedded in the source.
[ ] I tested the final version after the last change.

What this workflow cannot prove

A browser preview and syntax check cannot guarantee that a page is secure, accessible or correct. Server code, dependencies, authentication, payment flows, data handling and organisation-specific policies need their own review. Automated accessibility tools also miss problems that only a person completing the real task will notice.

Use the checklist as a strong first review—not as a substitute for appropriate security, accessibility or domain expertise.

If you want a browser workspace for the steps above, use the HTML editor and live preview or follow the longer canonical guide, Preview AI-generated HTML safely.

What is the most surprising mistake you have found in generated frontend code?