QUICK ANSWER
What you should remember
- Read the source before running it, especially scripts, forms and remote resources.
- Use a sandboxed preview that does not inherit the surrounding site's permissions.
- Replace secrets, private data and real submission URLs with harmless test values.
- Validate, test keyboard access and check the network requests before publishing.
Why generated HTML deserves a careful first run
An AI assistant can produce a convincing page in seconds, but visual polish does not prove that the code is safe, valid or maintainable.
Generated code may include scripts you did not request, third-party fonts, analytics tags, form actions, remote images, inline event handlers or placeholder links. Most are ordinary mistakes or copied patterns rather than deliberate attacks, but the effect can still be unwanted data sharing or a broken page.
Treat generated HTML like code from an unfamiliar repository: inspect it, run it with limited permissions, observe its behavior and only then move it into a real project. Never paste API keys, passwords, private customer data or authentication tokens into a public AI conversation or an untrusted preview.
- Search for script, iframe, form, object, embed and link elements.
- Check every URL and look for unfamiliar domains or plain HTTP resources.
- Look for fetch, WebSocket, localStorage, document.cookie and location assignments.
- Confirm that buttons and links describe what they actually do.
A five-step safe preview workflow
The safest useful workflow is simple enough to repeat every time.
- Save the original answer
Keep an untouched copy so you can compare changes and recover when an automated fix removes something important.
- Inspect before executing
Read the HTML, CSS and JavaScript. Remove unknown external scripts, real form endpoints and any credential-like values.
- Open an isolated preview
Use a viewer that renders the page in a sandboxed frame. Start without pop-ups, downloads, navigation or same-origin privileges.
- Observe behavior
Open the preview console, interact with every control and check failed or unexpected resource requests.
- Validate and publish deliberately
Fix syntax and accessibility issues, compare the final source with the original, then publish through your normal reviewed deployment.
Use the smallest set of iframe permissions
The iframe sandbox attribute blocks capabilities unless you explicitly allow them. Add a permission only when the demo genuinely needs it.
Avoid combining allow-scripts and allow-same-origin for same-origin content unless you fully trust it. That combination can weaken the isolation the sandbox is meant to provide. If a demo needs a capability such as forms, add only that token and test the result again.
html<iframe
title="Preview of generated code"
sandbox="allow-scripts"
referrerpolicy="no-referrer"
srcdoc="
<button id='hello'>Test button</button>
<script>
document.querySelector('#hello')
.addEventListener('click', () => alert('Works'));
</script>
">
</iframe>This example permits scripts inside the preview but does not grant same-origin access, form submission, downloads, pop-ups or top-level navigation. Real tools may also apply a Content Security Policy and rewrite the document before rendering.
Open the live HTML editorWhat to check before publishing
A clean preview is the beginning of review, not the end.
| Check | What good looks like | Useful next step |
|---|---|---|
| HTML structure | One doctype, meaningful landmarks, valid nesting and unique IDs | Run the HTML validator |
| Accessibility | Keyboard access, visible focus, labels, alt text and readable contrast | Run the accessibility checker and test manually |
| Resources | Every font, image and script comes from a domain you intentionally chose | Review the console and network activity |
| Forms | Labels, validation, privacy text and a controlled test endpoint | Submit only dummy data |
| Responsive layout | No horizontal overflow at narrow widths or enlarged text | Test phone, tablet and desktop previews |
| Source changes | You can explain every meaningful difference from the saved original | Use the HTML diff checker |
Three safety misunderstandings to avoid
These shortcuts feel reassuring but do not provide the protection people often assume.
- “It is only HTML” is misleading. An HTML document can load scripts, submit forms, embed remote pages and navigate the browser.
- “The preview looks correct” only confirms one visual state. It says nothing about hidden controls, network requests, keyboard access or edge cases.
- “The AI said it was secure” is not a security review. Ask the model to explain code, but verify behavior using standards, tools and human inspection.
Use these tools with the workflow
Each link opens an existing HTMLOnline tool or course that supports a specific part of the review.
Standards and primary references
These references support the standards and product-capability statements in this guide. Our workflows and examples are original.
- The iframe sandbox attributeWHATWG HTML Standard
- Content Security Policy Cheat SheetOWASP
- iframe sandbox referenceMDN Web Docs
Frequently asked questions
Is it safe to paste AI-generated HTML into a browser?
Inspect the source first and use a sandboxed preview that limits scripts, navigation, downloads and form submission. Do not include secrets or private data.
Does sandboxing make generated code completely safe?
No. Sandboxing reduces available capabilities, but source review, validation, accessibility testing and controlled publishing are still necessary.
Can HTML run JavaScript?
Yes. HTML can contain inline scripts or load remote JavaScript. It can also submit forms, embed other pages and request external resources.