HTML Viewer with CSS and JavaScript
An HTML viewer can render CSS and browser-side JavaScript when they are included in the document or loaded from reachable web URLs. For the most portable preview, place critical CSS in <style> and simple behavior in <script>.
Use a Self-Contained Document
This test includes a responsive card and a button that changes its status:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style>
body {
margin: 0;
padding: 2rem;
background: #f4f7fb;
}
.card {
max-width: 38rem;
margin: auto;
padding: 1.5rem;
background: white;
}
@media (max-width: 480px) {
body {
padding: 1rem;
}
}
</style>
</head>
<body>
<main class="card">
<h1>Complete page test</h1>
<p id="result">Waiting for interaction.</p>
<button id="check">Check JavaScript</button>
</main>
<script>
document.querySelector('#check').addEventListener('click', () => {
document.querySelector('#result').textContent = 'JavaScript works.';
});
</script>
</body>
</html>Run the document in the live HTML viewer, activate the button, and compare desktop and phone widths.
Inline vs External CSS
Inline CSS makes one-file previews easier to move and share. External stylesheets are better for a real multi-page site, but they must be publicly reachable:
<link rel="stylesheet" href="https://example.com/styles.css" />A local reference such as href="./styles.css" works only when that file is available beside the document in the same hosted structure. Uploading one HTML file does not automatically upload its neighboring assets.
Inline vs External JavaScript
Small tests can live inside a <script> element. External modules and libraries require valid URLs and may be affected by cross-origin policy, content security policy, authentication, or a server that blocks embedding.
Do not put private API keys in browser-side JavaScript. Anyone who can open the page can inspect its source.
The HTML viewer definition guide explains how rendered output differs from the source document. Use the live HTML viewer workflow when you need a repeatable edit, refresh, and check cycle.
Why CORS Errors Appear
Cross-Origin Resource Sharing is enforced by the server serving the requested resource. An HTML viewer cannot override a server that refuses a cross-origin request. Use an endpoint that explicitly allows the browser origin, or proxy the request through a backend you control.
What the Viewer Cannot Run
PHP, Python, Node.js server code, database queries, private environment variables, and build-time imports do not execute inside a static HTML document. Build the project first or deploy it to an application platform.
How the Browser Processes the Document
The browser does not treat HTML, CSS, and JavaScript as three unrelated files. It parses HTML into a document tree, applies matching CSS rules, calculates layout, paints pixels, and runs scripts at defined points in that process. A change in one layer can therefore appear to be a problem in another. A script may add a class, the class may activate a CSS rule, and that rule may move an element.
Source order matters. A blocking script in the document head can pause HTML parsing. A style rule loaded later can override an earlier rule with equal specificity. An inline declaration can outrank a normal style-sheet rule. Begin debugging by identifying when each resource loads and which final rule or script action affects the element.
A viewer is most predictable when the first version uses a complete document, inline critical styles, and a script placed near the end of the body or loaded with an appropriate defer strategy. Once that baseline works, move resources outward one at a time.
Build a Portable Baseline First
Start with meaningful HTML that remains understandable before styles or scripts run. Use headings for sections, buttons for actions, labels for inputs, and lists or tables for structured information. This baseline gives the preview useful content even if a later resource fails.
Add only the CSS needed to make the test recognizable. A small reset, a content width, spacing, and one component style are often enough. Avoid copying an entire production style sheet into a reduced example; unrelated rules make the cause harder to isolate. If the problem depends on a specific custom property or selector, include that dependency explicitly.
Add JavaScript last and keep its first behavior observable. Change a status message, toggle a class, or write a clear console entry. An observable action confirms that the script loaded, found its target, and responded to the event. Complex data fetching can follow after the browser-side path works.
Debug the CSS Cascade Systematically
When a rule appears not to work, first confirm that the style block or file loaded. Then confirm that the selector matches the intended element. Browser developer tools can show matched rules, crossed-out declarations, inherited values, and the computed result. This is more reliable than adding !important until the page changes.
Check specificity and source order. A class rule can be overridden by a more specific selector, an inline style, or a later rule of equal strength. Also check whether the property applies to that display mode. Width behaves differently for inline elements, and alignment properties depend on the parent being a flex or grid container.
Responsive rules add another layer. A declaration inside a media query applies only when its condition matches the preview width. Record the width where the layout changes, then inspect both sides of that boundary. If a mobile rule never activates, verify the viewport metadata and the query rather than compensating with arbitrary fixed sizes.
Run JavaScript at the Right Time
A script can fail because it executes before the element it needs exists. Placing the script after the relevant markup is a simple solution for a one-file example. A deferred external script also waits until parsing completes. Alternatively, listen for the document-ready event before querying elements. Choose one clear strategy rather than adding repeated delays.
Prefer event listeners over inline handlers in examples intended to grow. Inline handlers are quick for a tiny demonstration, but separate listeners keep behavior out of markup and make multiple interactions easier to organize. Confirm that selectors return elements before using them, and handle optional elements deliberately.
Every automatic refresh may execute the script again. Timers, network requests, storage writes, or analytics calls can therefore repeat during editing. Replace irreversible operations with test doubles. A preview should not create real orders, send real messages, or mutate production data.
Classic Scripts, Modules, and Origins
A classic script and a JavaScript module do not load under identical rules. Modules use strict mode, have their own scope, support imports, and are subject to origin and content-type requirements. A module import that works through a development server may fail when the same file is opened through a local file address.
Bare imports such as a package name are usually resolved by a bundler or an import map; the browser cannot infer a package directory by itself. For a standalone preview, use a browser-ready URL only when the source is trusted and the version is pinned. For application code, keep package resolution in the real project toolchain.
Origin also affects storage, requests, frames, and service workers. An embedded preview can have a different or opaque origin from the published page. Treat a successful one-file interaction as a component check, then repeat origin-sensitive behavior in the environment where it will actually run.
Diagnose Cross-Origin Requests
CORS is a rule enforced by browsers when script from one origin requests data from another. The remote server decides which origins may read its response. Adding a random request header or using a different HTML tag does not grant permission. The server must return an appropriate policy, or your architecture must use an approved same-origin backend.
Read the console and network entry together. Determine whether the request was sent, what status returned, whether a preflight occurred, and which response header is missing. A network status can look successful while the browser still prevents JavaScript from reading the body.
Do not paste private API keys into a client-side preview. Anything shipped in HTML or JavaScript is visible to the person who opens it. Public identifiers may be designed for browser use, but secrets belong on a server. Use mock JSON to validate layout before connecting the real endpoint.
Handle Images, Fonts, and Third-Party Libraries
Use reachable HTTPS addresses for remote assets and provide dimensions or stable layout constraints for images. Mixed HTTP resources may be blocked when the viewer itself uses HTTPS. Remote hosts can also reject embedding, require referrer information, or disappear later. A screenshot of a successful preview does not guarantee that dependency will remain available.
Web fonts can change line breaks after they load. Test once with the intended font and once with the fallback stack. The page should remain readable in both states. When the exact typeface is essential, host it under a license and delivery setup appropriate for the final site.
Third-party libraries should solve a real requirement. Pin versions and include integrity or organizational controls where the production workflow expects them. A one-line convenience import can add substantial code, tracking, or security surface. For a small interaction, native browser APIs may be simpler and more durable.
Test Failure States, Not Only Success
Disable the network and reload. The core content should remain understandable if the document is meant to be portable. Block one image, supply an empty data response, and trigger an invalid form value. Each failure state should produce a visible, useful outcome rather than a blank region.
Review keyboard interaction and focus after scripts modify the page. If a modal opens, focus should move appropriately and return when it closes. If content is inserted, the reading order should remain logical. CSS that visually reorders elements can differ from keyboard and screen-reader order, so inspect the underlying document structure too.
Check performance at a practical level. Very large embedded images, repeated render loops, and synchronous scripts can make a small preview feel slow. Reduce the example until the behavior is clear, then measure the complete project in its deployment environment.
From Viewer Test to Production
Record what the viewer test proves: the supplied document rendered in a particular browser, at tested widths, with the listed resources available. It does not prove backend behavior, authentication, production caching, content security policy, or every browser combination.
When moving the work into a project, follow the project's conventions for style organization, modules, asset imports, error handling, and tests. Re-run the visual and interaction checks after the move. A bundler may transform paths, scopes, and load order, while production security headers may block code allowed in an isolated preview.
Before sharing or deploying, remove diagnostic outlines and logs, replace mock data deliberately, scan for credentials, and verify all remote domains. Keep the reduced viewer document as a reproducible example when it explains a bug, but label it with its purpose and date.
Frequently Asked Questions
Can an HTML viewer display CSS?
Yes. CSS inside style elements or reachable external stylesheets can style the rendered document.
Can an HTML viewer execute JavaScript?
It can execute browser-side JavaScript allowed by the preview environment. Server-side JavaScript and private backend code do not run in a static preview.
Why do local images and CSS disappear?
Relative assets are separate files. A one-file upload cannot access files that remain on your computer, so use reachable URLs or package critical assets into the document.