Three languages · One result

Online HTML, CSS and JavaScript Editor

Build interactive pages with the HCODX HTML, CSS and JavaScript editor. Link your files, preview button behavior and inspect console output.

HTML structureCSS stateJavaScript behavior
The contract

Give each file one job and one shared vocabulary

A working interaction is a small agreement between a document node, a visual state and an event handler.

A button can look perfect but do nothing if JavaScript queries an id that does not exist. A click handler can run correctly yet appear broken if CSS hides the updated result. Testing the three layers together catches these mismatches earlier than reading each file in isolation.

Start with one small behavior. Make sure the HTML works without a script, then add styling, then attach the event. That sequence gives you a known-good baseline if the final preview changes unexpectedly.

HTML

Use a real button element and a labelled output rather than a clickable generic div.

CSS

Keep interactive states visible, including focus-visible for keyboard users.

JavaScript

Query the correct element and attach the listener after the document is available.

Working example

Build a counter without a framework

The example is intentionally small: a button, an output, a focus style and one event listener.

Create the HTML and CSS first, then add the JavaScript. If you use separate files, link styles.css from the document and load app.js with defer so the elements exist before the query runs.

Click the button twice and confirm that the output reaches 2. Then use the console to investigate if the button does nothing: a null result from querySelector usually means the selector and markup disagree.

The aria-live output announces the updated count to assistive technology without moving keyboard focus.
<!-- index.html -->
<link rel="stylesheet" href="styles.css">
<button id="add" type="button">Add one</button>
<output id="count" aria-live="polite">0</output>
<script src="app.js" defer></script>

/* styles.css */
#add:focus-visible { outline: 3px solid #2947ff; outline-offset: 3px; }

// app.js
const button = document.querySelector("#add");
const count = document.querySelector("#count");
let value = 0;
button.addEventListener("click", () => { count.textContent = String(++value); });
When nothing happens

Debug the join between files

Most first-project failures are connection mistakes, not difficult algorithms.

Match the selector Compare #add and #count in JavaScript to the exact id attributes in HTML. Case and spelling must match.
Check script timing Use defer on an external script or attach the listener after the elements are parsed.
Read the first console error A TypeError about addEventListener on null points to the query; a syntax error points to the script itself.
Re-test keyboard behavior Tab to the button and press Enter or Space. A real button provides these interactions without custom key handling.

For a larger site, split related behavior into modules and use a build system when needed; the HCODX editor is a focused front-end workspace, not a server runtime.

Choose the runtime

What the three front-end files can run by themselves

HTML, CSS and JavaScript cover the page that reaches the browser; they do not automatically supply a backend.

Compare

Works in the preview

Markup, styling, DOM events, timers and other browser APIs allowed by the preview frame and browser permission model.

Compare

May depend on another origin

Fetching data from an API, embedding third-party scripts or loading remote assets depends on network availability, permissions and the remote service.

Compare

Needs another environment

PHP execution, private database queries, server-only secrets, build steps and authenticated backend routes are not produced by a front-end preview.

A second interaction

A form can validate locally without pretending to send data

The browser can check an email-shaped value and update the page. Saving or emailing that value is a different, server-backed task.

This example uses a real form and a labelled email input. The required and email attributes give the browser a first validation pass. When the input passes that check, the submit handler prevents navigation and writes an explicit local-only status message. There is no fetch request or storage call, so the form has not delivered anything to a person or database.

That distinction matters when testing generated interfaces: a success message can look like proof of submission even when no backend exists. If you later add an API, handle its response and failure states separately. Do not embed the API’s private credential in app.js; visitors can inspect front-end code.

Native input validation handles malformed values; the script reports only what it actually did.
<!-- index.html -->
<form id="email-check">
  <label for="contact-email">Email</label>
  <input id="contact-email" type="email" required>
  <button type="submit">Check email</button>
  <p id="status" role="status"></p>
</form>
<script src="app.js" defer></script>

// app.js
const form = document.querySelector("#email-check");
const status = document.querySelector("#status");
form.addEventListener("submit", event => {
  event.preventDefault();
  status.textContent = "Valid format. Nothing has been sent.";
});
Behavior QA

Test the states around the happy path

A control is not finished just because one click works with ideal input.

01

Use the keyboard

Tab to controls, submit a form with Enter and check that focus remains understandable after a result appears.

02

Try missing and malformed input

Confirm required fields and type constraints behave as intended. Write an error message if custom validation adds rules the browser does not know.

03

Check repeated actions

Click twice or submit twice. Ensure the handler does not duplicate output, attach itself again or leave stale status on screen.

04

Separate success from transport

When a backend is involved, do not show “sent” before the request has actually succeeded; display a recoverable failure state when it does not.

Before you run

Three-language project questions

No. The preview executes browser-side HTML, CSS and JavaScript. PHP and private database access need a server or hosted API.

Browser requests work when the API permits the preview origin through CORS and any needed credentials are safe for client-side use. Never place secret keys in front-end code.

Check relative paths to scripts, styles and assets. A path is interpreted relative to the referencing document, and moving files changes that relationship.

No. A small button, form or disclosure can often use native HTML and a few lines of JavaScript. Add a framework when its component or application tooling solves a real project need.

The selector may not match an element, the id or class may be misspelled, or the script may run before the element is parsed. Check the markup and script timing first.

CSS can style states, but changing actual text content in response to a click normally needs JavaScript. The counter example updates an output element through an event listener.

No. Anything delivered to a browser can be inspected by its user. Keep secrets in a backend and expose only a controlled API to the front end.

HTML and CSS can render even when JavaScript throws an exception. Read the first console error, check the script path, and confirm the event target exists.

Make the button do something

Create the three files, run the counter and follow the first error if it fails.

Instant HTML Runner & Viewer with Live Preview

Need to run a short HTML, CSS and JavaScript snippet? The HTML Runner Online has a focused editing surface with live output.

Open HTML Runner Online