🤖 AI

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

HTMLCure introduces a state-guided browser experience framework that evaluates and repairs interactive HTML through deterministic interaction trajectories, significantly expanding a seed corpus into a high-quality dataset that enables a 27B model to achieve performance comparable to leading systems like Kimi-K2.6 and GPT-5.4 on interactive web benchmarks.

Original authors: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Published 2026-05-27

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jiajun Wu, Jian Yang, Tuney Zheng, Wei Zhang, Haowen Wang, Yihang Lou, Xianglong Liu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: "Looks Good, But Broken"

Imagine you ask a very talented artist (an AI) to build a toy car. The artist hands you a beautiful model. It looks perfect in the photo. But when you try to push it, the wheels fall off. When you try to steer it, the steering wheel spins uselessly.

This is the current problem with AI-generated web pages (HTML). They often look great in a single snapshot (a screenshot), but when a real person tries to click buttons, scroll down, resize the window, or play a game, the page breaks.

The Old Way: Researchers used to take a photo of the page, check if it looked pretty, and decide if it was "good." This missed all the broken wheels.
The Result: They threw away thousands of pages that were actually fixable, or they kept pages that looked good but didn't work.

The Solution: HTMLCURE (The "Test Drive" Mechanic)

The authors built a system called HTMLCURE. Instead of just looking at a photo, HTMLCURE acts like a mechanic who takes the car for a test drive.

Here is how it works, step-by-step:

1. The Test Drive (Browser Experience)

Instead of just taking a picture, HTMLCURE loads the web page into a real browser. It doesn't just sit there; it actively interacts with it:

It scrolls up and down.
It resizes the window (like checking if a car fits in a small garage).
It clicks buttons, hovers over links, and tries to play games.
It records exactly what happens: "The button didn't work," "The game froze," or "The layout broke on mobile."

Analogy: Think of this as a driving test for a car. You don't just look at the paint job; you drive it to see if the engine starts, if the brakes work, and if the transmission shifts smoothly.

2. The Diagnosis (State Signal)

After the test drive, the system gives the page a "health score" and a diagnosis. It categorizes the page into three groups, like a doctor triaging patients:

Low Score (The Wreck): The page is a mess. It's missing big chunks of structure.
- The Fix: Total Rewrite. Don't try to patch it; build a new car from scratch.
Mid Score (The Clunker): The page works mostly, but has specific broken parts (e.g., the radio doesn't work, or the door handle is stuck).
- The Fix: Targeted Repair. Diagnose the specific broken part and fix just that.
High Score (The Sports Car): The page is already great.
- The Fix: Polish Only. Don't touch the engine; maybe just wax the paint. If you try to "fix" something that isn't broken, you might break it.

Key Insight: The paper claims that using the same repair method for all pages is a mistake. You need a different strategy depending on how broken the page actually is.

3. The Repair Loop (The Feedback Cycle)

Once the system decides on a strategy (Rewrite, Patch, or Polish), it asks the AI to fix the page.

Crucial Step: The system doesn't just trust the AI's word. It takes the new version of the page and runs the Test Drive again.
The Gatekeeper: If the new version is better, it keeps it. If the new version is worse (a "regression"), it throws it away and tries again.
The Goal: It keeps doing this until the page passes a high-quality standard (a score of 97/100).

Analogy: Imagine a chef tasting a soup. If it's too salty, they add water. Then they taste it again. They don't just assume the water fixed it; they verify it. If they add too much water and it's now too bland, they stop and try a different recipe.

The Results: Building a Better Library

The authors used this system on a huge collection of 97,000 AI-generated pages.

They started with a small pile of "perfect" pages.
They used HTMLCURE to fix the "broken" ones.
They ended up with 63,000 high-quality, verified pages (up from the original small set).

They then used this new, cleaned-up library to train a new AI model (called HTMLCure-27B).

The Outcome:

The new model is significantly better at making working web pages.
It scored 50.6 on a strict test called HTMLBENCH, which is on par with top-tier commercial models (like Kimi-K2.6 and GPT-5.4).
On a different test (MiniAppBench), it improved by 15 points compared to the untrained version.

Summary in One Sentence

HTMLCURE is a system that stops AI from just "guessing" if a web page works; instead, it forces the AI to test-drive every page, diagnose exactly what is broken, repair it using the right strategy, and re-test it to ensure the fix actually worked, creating a massive library of high-quality, working code.

Technical Summary: HTMLCure

Problem Statement

Large Language Models (LLMs) have demonstrated the ability to generate full HTML pages, but these outputs often suffer from a "superficial correctness" problem. While a generated page may render correctly in a single static screenshot, it frequently fails under dynamic conditions such as scrolling, hovering, clicking, resizing, or gameplay. Traditional evaluation methods relying on static screenshots or sparse visual traces miss these interaction-specific failures. Furthermore, standard data filtering approaches discard many of these pages as unusable, failing to recognize that they are often repairable. The core challenge identified is that data construction for interactive HTML is a state estimation problem rather than merely a scoring problem; static observations cannot reveal failures that only manifest after specific user interactions.

Methodology

The paper introduces HTMLCURE, a browser experience framework designed to evaluate, diagnose, and repair interactive HTML through a closed-loop process driven by browser execution traces.

1. Multi-Dimensional Experiential Evaluation Pipeline

Instead of relying on static screenshots, HTMLCURE evaluates an HTML artifact ( $h$ ) by executing a sequence of viewing and interaction actions ( $\pi$ ).

Four-Layer Experience Protocol:
- L1 (Visual Observe): Checks loading behavior and initial rendering.
- L2 (Active Interact): Exercises controls, hover states, keyboard bindings, and scroll behavior.
- L3 (Deep Gameplay): Runs task-driven rollouts for games or complex UIs to verify state transitions, counters, and canvas changes.
- L4 (Responsive): Selects representative keyframes from the execution trajectory with event context.
Structured Evidence: The evaluator produces an ordered trace $E(h, \pi)$ containing visual evidence ( $v_t$ , e.g., rendered frames) and behavioral evidence ( $b_t$ , e.g., DOM state, console errors, probe outcomes).
Five-Component Scoring: A score $S(h)$ is derived from five dimensions: Rendering, Visual Design, Functionality, Interactivity, and Code Quality. Crucially, Visual Design is the only component judged by a Vision-Language Model (VLM) based on curated keyframes; all other dimensions rely on deterministic browser execution and static analysis.

2. State-Aware Interactive Repair Engine

The repair process is not a generic regeneration but a controlled intervention based on the page's current state.

State Routing: The system classifies pages into three states based on their score $s$ $s$ :
- Low (< 40): Pages with no stable local target. Strategy: Holistic Rewrite.
- Mid (40–79): Pages with usable structure but broken behavior. Strategy: Diagnosis-Guided Local Repair (e.g., fixing specific interaction bugs).
- High (≥ 80): Strong pages. Strategy: Preservation or Targeted Refinement to avoid regression.
Closed-Loop Execution: The controller selects a repair family, prompts the LLM for candidates, and re-executes every candidate in the browser.
Regression-Aware Acceptance: Candidates are selected using a composite score $S_{comp}$ that penalizes regressions in functionality and interactivity, ensuring that improvements in visual design do not come at the cost of broken logic.
Termination: The loop stops when a page reaches a high target score (≥ 97), gains plateau, or the round budget is exhausted.

3. Data Construction

HTMLCURE treats repair as a data construction mechanism. Accepted repairs from the initial 97K prompt corpus are exported into a refined Supervised Fine-Tuning (SFT) pool. This process expands the usable dataset from a small subset of "High" pages to a larger pool of 63,703 quality-cleared pages, from which a final 40K training set is constructed.

Key Contributions

Browser Experience as a Repair State Signal: The paper demonstrates that converting browser execution traces into structured page states allows for precise bounding of VLM visual judgment and drives specific repair decisions.
State-Aware Interactive Repair: The framework introduces a policy where the repair strategy (Rewrite vs. Diagnose vs. Preserve) is dynamically selected based on the observed state of the page. This prevents the destruction of working components in high-quality pages and ensures structural reconstruction for low-quality ones.
Repair as Data Construction: By validating repairs through re-execution, the system creates a high-quality, verified SFT corpus. This approach transforms the "filtering" paradigm (discarding bad pages) into a "recovery" paradigm (repairing and verifying pages).

Results

The authors evaluated the methodology using HTMLBENCH-400, a deterministic browser-executable benchmark, and the MiniAppBench validation split.

Performance: Under the same backbone (Qwen3.5) and training recipe, the HTMLCure-27B-Refined model achieved:
- 50.6 on HTMLBENCH-400 (Total Score).
- 45.2% deterministic test case pass rate.
- 81.2 average on the MiniAppBench validation split.
Comparisons: These results place the model in the same performance band as strong reference systems like Kimi-K2.6 and GPT-5.4.
Ablation: Controlled experiments with equal data sizes (12,392 examples) confirmed that the "Refined" route (using repaired, verified data) outperforms both "Raw" (original generations) and "Filtered" (only original high-quality pages) routes, proving that the quality of supervision derived from browser experience is the primary driver of improvement, not just data volume.

Significance and Claims

The paper claims that HTMLCURE shifts the paradigm of interactive HTML generation from "generate and filter" to "experience, repair, and verify."

Execution as Control: The central claim is that browser execution should not be used merely as a final pass/fail judge but as a continuous control signal that separates missing structure from broken interaction.
Data Quality: The work demonstrates that repairing weak and partial pages under state-specific control yields stronger supervision for SFT than simply selecting pre-existing high-quality pages.
Reproducibility: The authors provide a frozen benchmark (HTMLBENCH) with deterministic test cases and a full pipeline for reproducible comparison, moving beyond agent-based evaluations that lack standardized failure records.

The paper remains modest regarding its limitations, acknowledging that the VLM is still required for bounded visual design scoring, browser probes cannot cover every possible interaction, and complex games may expose coupled timing failures. It suggests future work could involve learning routing and stopping policies directly from repair traces.