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?

DEV Community: Tusing1