html-runner.landing Open editor

html/runner

Run HTML Code Online with a Fast HTML Runner

Execute HTML, CSS and JavaScript instantly with live preview, a browser console sitting beside the page, responsive device testing and nothing at all to install.

Run HTML online See the console
executionyour browser
consolebeside the page
devicesreal frames
run buttonnone needed
app.js
const res = await fetch('./data.json')
const items = await res.json()

console.table(items)

document.querySelector('#list').innerHTML =
  items.map(i => `<li>${i.name}</li>`).join('')
running

01 platform

What running a page in a tab actually gives you

A page is not a snippet that produces output — it is a document with a lifecycle, a console and a viewport. Running it properly means having all three.

  • There is no Run button

    The page executes as you type. A <script> re-runs when its file changes, so the loop is edit-and-look rather than edit-and-click.

  • The console is beside the page, not behind a shortcut

    console.log, console.table and thrown errors land where you can read them without leaving the tab or remembering to open devtools.

  • Errors point at your file and line

    An uncaught throw reports the file, the line and the stack, rather than an offset in something concatenated together.

  • Real device frames, not a resized window

    Responsive testing at genuine device dimensions with the right pixel ratio, which is where most media-query bugs actually surface.

02 pipeline

What happens between saving and seeing

Four stages, all in the browser, and none of them a build. Knowing the order explains most of what looks like a mysterious render.

  1. Parse

    The markup becomes a DOM. The parser never refuses — it recovers from anything — which is why a structural mistake shows up as a layout surprise rather than an error.

  2. Style

    Stylesheets are matched against the tree and the cascade resolves. A selector that stops matching after an edit almost always means the tree changed, not the CSS.

  3. Execute

    Modules load and run in order. type="module" is deferred by definition, so a script at the top of the document still sees a complete DOM.

  4. Paint

    The result renders in the preview, updated in place rather than reloaded, so scroll position and page state survive the edit.

03 workflow

Reading the console while the page runs

One real sequence, from a page that works to one that throws and back. Nothing here needed devtools opened.

session
  • run → index.html
  • DOM ready · 3 modules loaded
  • [table] 4 rows from data.json
  • TypeError: items.map is not a function
  • at app.js:7:22
  • fix → await res.json() → save
  • re-executed · 0 errors

  • Output keeps its ordering

    Logs, warnings and throws interleave the way the page produced them, which is the information a separate panel makes you reconstruct.

  • console.table and friends work

    The console is the browser's own, so structured logging, grouping and timing all behave as documented.

  • Recovery is one save

    Fix the line and save. The scripts re-run in place; there is no server to restart and no cache to clear.

04 deep dive

Testing on a phone without owning one

Most responsive bugs are not visible in a resized desktop window, because a resized window is not a phone.

Device frames use real dimensions. A viewport of 390×844 at 3× pixel density behaves differently from a 390px-wide desktop window, and media queries that look fine in one fail in the other.

Touch versus hover changes the CSS. @media (hover: hover) and (pointer: coarse) resolve differently in a device frame, which is where a hover-only interaction reveals itself as unusable on a phone.

dimensions
real device sizes
dpr
matched
pointer
coarse / fine
placement
split or full
styles.css
@media (pointer: coarse) {
  .menu a { min-height: 44px }
}

@media (hover: hover) {
  .card:hover { transform: translateY(-2px) }
}

05 features

What you can run

Anything the browser can execute runs here, because the preview is a browsing context rather than a sandbox with its own rules.

  • ES modules and dynamic imports

    type="module", top-level await and import() all work, with npm packages importable by name.

  • fetch and local files

    Fetch remote APIs or a ./data.json sitting in the project. Both resolve, because the preview serves a real directory.

  • Storage and state APIs

    localStorage, sessionStorage, IndexedDB and cookies behave normally, so a persistence bug reproduces here.

  • Canvas, WebGL and animation

    2D canvas, WebGL, the Web Animations API and requestAnimationFrame all run at full speed on your own GPU.

  • Modern platform features

    <dialog>, view transitions, container queries, :has() — whatever your browser supports, the preview supports.

  • Offline, once loaded

    XCODX installs as a Progressive Web App, so running and editing keep working with no connection.

06 ecosystem

A page that runs beside other languages

A plain .html file can sit beside a React component and a Python script; XCODX picks the right handling per file rather than per project.

  • React
  • Vue
  • Angular
  • Svelte
  • SolidJS
  • Lit
  • HTMX
  • Vite
  • TypeScript
  • JavaScript
  • HTML
  • CSS
  • SCSS
  • Less
  • Pug
  • Tailwind
  • Bootstrap
  • Vuetify
  • Ant Design
  • shadcn/ui
  • Phaser
  • Node.js
  • Python
  • Java
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • SQL
  • Bash

07 languages

Every language the editor can run

Highlighting and IntelliSense cover 70+ languages. These are the ones XCODX also compiles or executes for you.

Compiled in your browser11

Zero build step. Transform runs on a Web Worker, so typing never blocks.

  • JSX
  • TSX
  • TypeScript
  • Vue SFC
  • Svelte
  • Angular (JIT)
  • SolidJS
  • SCSS
  • Sass
  • Less
  • Pug

Rendered natively8

Straight to the live preview, no transform in the way.

  • HTML
  • CSS
  • JavaScript
  • JSON
  • Markdown
  • Jupyter (.ipynb)
  • SVG
  • YAML

Executed on demand22

70+ languages run through a self-hosted Piston engine. stdout, stderr, images and tracebacks land in the console.

  • Python
  • Java
  • C
  • C++
  • C#
  • Go
  • Rust
  • Ruby
  • PHP
  • Kotlin
  • Swift
  • Lua
  • Scala
  • Perl
  • Haskell
  • Elixir
  • Dart
  • R
  • Julia
  • SQLite
  • Bash
  • PowerShell

08 questions

Running HTML online — common questions

Questions about execution specifically.

Where does my code actually run?

In your own browser, on your own device. There is no execution server, which is why there is no queue, no cold start and no copy of your source sitting on somebody else's machine.

Is there a Run button?

No, and that is deliberate. The page updates as you type — markup and styles repaint in place, and a changed script re-executes. Pressing a button to see your own edit is a step worth removing.

Can I see console output without opening devtools?

Yes. Logs, warnings, tables and thrown errors appear in a console beside the page, in the order the page produced them. Devtools still work if you prefer them.

Does fetch work, including to my own files?

Both. Remote APIs work subject to their CORS headers, and a local ./data.json resolves because the preview serves a real directory rather than a concatenated document.

Can I test how a page looks on a phone?

Yes, in real device frames rather than a resized window. Dimensions and pixel ratio are matched, and (pointer: coarse) and (hover: hover) resolve the way they would on the device.

What happens when my JavaScript throws?

The error is reported with the file, the line and the stack, and the page stays on screen rather than going blank. Fix the line, save, and the scripts re-run in place.

Can I run anything server-side?

No. Running in a browser means there is no Node process, so API routes, file-system access and server rendering are out of scope. Everything client-side runs completely.

Does it work offline?

Once loaded, yes. XCODX installs as a Progressive Web App and everything executes on your device, so editing and running keep working with no connection.

Do I need to install anything to use XCODX Studio?

No. XCODX Studio is a browser-based IDE — the editor, the compilers and the preview all run client-side. There is no download, no package manager to set up and no configuration file to write. Opening the editor is the whole setup step.

Where is my code stored?

In your own browser. Projects, file history and Git objects live in local storage on your device and are never uploaded to a server. That also means XCODX works offline: it is a Progressive Web App, so you can install it and keep coding with no connection.

Is XCODX Studio free?

Yes. The editor, the live preview, the 70+ language runtimes, npm installs, Git and the integrated terminal are all free to use.

Can I use XCODX on a tablet or Chromebook?

Yes. The editor is a responsive web app, so a Chromebook, an iPad or an Android tablet gets the same compilers and the same preview a laptop does — there is no desktop-only build, because there is no build to install at all. The layout adapts to the screen rather than shrinking a desktop UI into it.

Can I export a project or move it to my own machine?

Yes. Export the whole project as a zip with its folder structure intact and open it locally, or commit it and push. It is ordinary source on disk from that point on — no proprietary format and no lock-in, which is also why importing an existing repository from GitHub works the same way in reverse.

Nothing to install

Run HTML code online now

A page executing in seconds with the console beside it, real device frames, and no Run button to press.

Run HTML online Read the docs