Image-to-Code: A Dataset & Benchmark for Full-Stack Web Reconstruction

1. Dataset introduction

Screenshot-to-code tasks typically require a model to reproduce the appearance of a single page. L3 advances the task to realistic software development: a project contains multiple interconnected pages, page actions must connect to backend APIs and persistent data, and the result of one action may be a prerequisite for the next. The model must answer not only “What does the page look like?” but also “Who can perform an action, how does the data change, what should other pages display afterward, and can the entire project be started and verified?”

This dataset uses the page structures, visual styles, and business context of real websites to create deliverable full-stack reconstruction tasks. It targets agents capable of reading multimodal materials, understanding requirements, and writing and debugging applications. It primarily trains and evaluates end-to-end capabilities from requirements to engineering implementation, rather than merely generating visually similar static pages. The key capabilities are requirements understanding, interface reconstruction, frontend–backend and database integration, complex state management, and debugging and deployment delivery.

The difficulty of L3 is not simply the number of pages; it is the interaction among constraints. For example, a user filters a list, opens a detail page, signs in to make a reservation, modifies the reservation, and returns to the list. Every interface response must remain consistent with the same data and authentication state. A few clickable buttons cannot satisfy this task.

Standardized project delivery structure

<case>/
├── task.toml
├── manifest.json
├── instruction.md
├── prd.md
├── prototypes/desktop/
├── resources/
│   ├── images/  icons/  fonts/  (css/)
├── solution/
│   ├── solve.sh
│   ├── start.sh
│   └── app/
│       ├── (frontend) public/ and other page assets
│       ├── (backend) app.py / server.py
│       ├── data/           # SQLite database + seed data
│       ├── requirements.txt / package.json
│       └── start.sh
├── environment/
│   ├── Dockerfile  build.sh  preflight.sh
│   ├── package.json  package-lock.json
│   ├── requirements.in  requirements.lock
│   ├── render_screenshots.sh
│   ├── context/render-prototypes.js
│   └── preprocess/verify_layout.py
└── tests/
    ├── test.sh
    ├── v2w_grade.py
    ├── vision2web_official.py
    ├── backend.py  (backend_checks.py)
    ├── checks.py
    └── workflows.json

We constructed an evaluation set of 50 projects and tested leading multimodal models under the same scoring rules.

2. Dataset design

2.1 Visual complexity design

The data design spans different types of businesses instead of generating pages from a fixed template. Its complexity is benchmarked against real websites. Real sites are distilled, redesigned, and reorganized while preserving their varied navigation hierarchies, module density, layout rhythm, text-to-image ratios, and combinations of assets. Models must first understand each project’s information architecture and then determine reusable components, page layouts, and routing, rather than relying on a single page template. Site selection focuses on whether pages form meaningful navigation and business dependency chains. The L3 initial screening stage of the production pipeline requires 7–12 valid pages and strictly more than 50 unique images after site-wide deduplication to ensure rich page resources. It also verifies that page dependency chains are complete.

Project categories include:

Page-complexity metrics for the evaluation set (50 projects):

Following the evaluation approach in Design2Web, page complexity is characterized by average tag count, DOM depth, and number of tag types.

• Average tag count: total number of HTML tags per webpage.
• DOM depth: maximum nesting depth of the DOM tree, measuring structural nesting complexity.
• Number of tag types: number of distinct HTML tag names per page after deduplication, measuring tag diversity.

The samples in this dataset differ from WebSight in complexity as follows:

2.2 Functional complexity design

Project functionality covers feature coverage, API diversity, multi-table queries, state dependencies, CRUD operations, and media operations. Complexity is primarily ensured through coupling between features. The feature set has two parts: existing features collected and reconstructed from the original site, followed by additional features consistent with its business logic. Together, these ensure sufficient functional scale and complexity while retaining authentic business logic.

When normalizing feature cards, the production pipeline requires at least 21 distinct `method + path` APIs, including at least 8 POST/PUT/PATCH/DELETE APIs; at least one genuine dependency chain in which a response value is passed to a subsequent request; and at least two GET APIs declaring multi-table query relationships. These are production-stage requirements for contract coverage. The following table reports actual means for the 50 samples.

3. Metric design

3.1 VS Visual Score

A vision-language model (VLM) judge compares a prototype image with a screenshot of the implemented page. It automatically divides them into logical functional blocks based on visual structure and function, scores each block with a five-level rubric, and provides a rationale. Averaging all block scores gives the VS for one prototype. Averaging across all prototypes and multiplying by 100 produces an interpretable score for how faithfully the pages have been reconstructed.

3.2 FS Functional Score

A GUI agent performs actions and checks assertions node by node in each workflow in a real browser. Each functional validation node is classified as Pass, Fail, or Blocked. The functional score is the pass rate: passed nodes ÷ total validation nodes × 100. Setup nodes are excluded. Fail and Blocked nodes receive no credit. Assessment primarily uses three workflow fields:

Setup node: the first node in each workflow has empty validations and an objective beginning with Open the <page>. It only navigates to the page and establishes the state needed later (navigation, sign-in, or prior data creation); it contains no assertions.

3.3 DSR Deployment Startup Rate

This metric tests whether a model can produce a complete, runnable project end to end. Data production supplies a startup script using a fixed port. Evaluation runs that script to determine success, allowing at most three attempts. Failure to start within 10 minutes, or an error during startup, is classified as failure. The score is the success rate: successfully started projects ÷ total projects. This metric assesses whether projects can run reliably.

The final overall score is calculated as:

4. Summary of model reconstruction scores

4.1 Overall scores

Ranking by mean score:

GPT-6 Astra (54.15) > GPT-6 Sol (46.29) > DeepSeek V4.1 Flash (42.26) > Gemini 3.8 Flash (35.68) > Qwen3.8 Max (35.11) > Doubao Seed 2.0 Pro (16.66)

4.2 Component metric scores

The scores are as follows:

5. Error pattern analysis

5.1 Error pattern definitions

5.1.1 FS error pattern definitions

5.1.2 VS error pattern definitions

5.2 Differences between models across FS dimensions

5.2.1 Dimension analysis

Overall findings:

• Model strengths: navigation and routing; search, filtering, and sorting.
• Model weaknesses: form interactions, state management, authentication and authorization, CRUD operations, and UI feedback.
• Scores for files and media are relatively low, but the small sample size does not support strong conclusions.

5.2.2 Model performance by dimension

• GPT-6 Sol: particularly strong in navigation and search; forms and files / media are its weaker dimensions.
• Qwen3.8 Max: performance is relatively concentrated across dimensions; CRUD is its lowest dimension.
• DeepSeek V4.1 Flash: better at navigation, search, and feedback; weaker in authentication and forms.
• Gemini 3.8 Flash: strong in search, with forms a clear weakness.
• GPT-6 Astra: strong overall and leads the other models, although files / media and authentication are relatively weaker areas for this model.
• Doubao Seed 2.0 Pro: low pass rates across many dimensions; forms and state management especially need improvement.

5.3 Differences between models across functional submetrics

The following table shows each model’s scores for the different submetrics. Values are pass rates (%) for tests associated with each error pattern. Red marks the highest rate and green the lowest rate in each row. Yellow identifies the most frequent error pattern within each dimension, as highlighted in the source.

5.3.1 Submetric difficulty analysis

• Navigation and routing: making pages navigable is relatively easy; interaction switching, such as tabs and expand / collapse controls, is more likely to fail.
• State management: synchronization across components is harder than session persistence. The shared difficulty is keeping multiple parts of the interface synchronized.
• Form interactions: format validation, boundary validation, and agreement gating are the main difficulties. Boundary validation is broadly challenging, while format validation clearly differentiates models.
• UI feedback: success feedback is substantially better than error feedback. Feedback for the normal success path is easier to implement well than feedback for exceptional paths.
• Authentication: authentication is about more than whether a sign-in page exists. Session termination and access handling for protected pages are also significant challenges.
• CRUD operations: editing and deletion are the most consistent weaknesses, rather than reading and displaying data.
• Search, filtering, and sorting: basic search and filtering are relatively easy; correctness of data and state after pagination is harder to validate successfully.
• Files and media: downloading is relatively stronger, playback is weaker, and evidence for uploading is insufficient.

Summary: the well-supported shared difficulties are error feedback, saving edits, deletion, boundary validation, and cross-component synchronization. Links, reads, search, and filtering are relatively easier.

5.3.2 Error pattern analysis by model

This analysis considers the strengths and weaknesses of each model individually.

5.3.3 Summary of differences between models

The following comparisons identify which models perform better on particular error patterns.

• GPT-6 Sol has broad strengths concentrated in navigation, CRUD, and retrieval workflows.
• Qwen3.8 Max has its clearest advantages in form validation, sign-in validation, and access control.
• DeepSeek V4.1 Flash stands out in success feedback and some interactions, but is weaker in unauthenticated redirects and confirmation dialogs.
• Gemini 3.8 Flash is stronger in reads, filtering, and sorting; form rules are a clear weakness.
• GPT-6 Astra has the highest scores among the six models for success feedback, interaction switching, format validation, and password rules. Sorting, reads, search, filtering, and links also remain high, while error feedback, access control, editing, and deletion remain relatively weak.
• Doubao Seed 2.0 Pro trails in most error patterns with large samples, but is not lowest on every submetric. For example, it is not last in the current small-sample audio / video results.

Format validation, required-field validation, access control, confirmation dialogs, and pagination best reveal differences between models. The most consistent shared weaknesses are error feedback, saving edits, and deletion.

5.4 Differences between models across VS dimensions

The following table shows the distribution of visual error patterns for each model. Values are shares of visual defects (%). Red marks the highest share and green the lowest share for each error pattern.

5.4.1 Dimension analysis

• Layout and missing blocks are the two most concentrated error categories, totaling approximately 64.6%. Current visual errors mainly concern page layouts, dimensions, spacing, and positions that differ from the prototype, and prototype blocks or components that are not rendered.
• Navigation and headers are the third shared area of concern, with a global share of 11.5%. The six models lie at approximately 9.3%–13.2%, a relatively narrow range.
• Extra blocks, text, and images have lower shares but still matter: extra blocks account for 8.5%, text / data / content mismatch for 8.1%, and image / media mismatch for 6.6%. Image and text shares vary noticeably across models and must be examined separately for each model. Global shares alone should not determine priorities.

Conclusion: prioritize layout accuracy, block completeness, and navigation / headers overall.

5.4.2 Differences between models

• Qwen3.8 Max and DeepSeek V4.1 Flash: layout / structure / size / position mismatch is a weakness.
• Gemini 3.8 Flash: block completeness and layout are weaknesses.
• Doubao Seed 2.0 Pro: block completeness is a weakness.
• GPT-6 Sol and GPT-6 Astra: in addition to layout and missing blocks, content matching deserves more attention. GPT-6 Sol also has a relatively high share of image problems.

5.5 Analysis reports for the six models

1. GPT-6 Sol

FS: main weaknesses are forms, some authentication workflows, and files / media.

VS: layout is the main problem; images and text also need close checking.

Overall assessment: broad functional strengths, with good performance in search, navigation, and CRUD. However, error feedback, input validation, and some authentication workflows remain unstable. Visual improvements should address image selection and content consistency as well as layout and missing blocks.

2. Qwen3.8 Max

FS: relatively strong forms, but weaker data operations and synchronization.

VS: errors are heavily concentrated in layout accuracy.

Overall assessment: form rules are a relative strength, but better validation has not fully translated into better data changes and state synchronization. Visually, prioritize checking whether layout, dimensions, spacing, and positions match the prototype.

3. DeepSeek V4.1 Flash

FS: access control and forms are the main weaknesses.

Overall UI feedback reaches 58.6%, but there are substantial internal differences: success feedback is 69.9%, error feedback 31.4%, and confirmation dialogs 28.6%.

VS: layout and extra blocks are the key inspection points.

Overall assessment: feedback on routine success paths is better, but permission restrictions, unauthenticated access handling, and confirmation actions are weaker. Visual problems center on layout and structure: check both whether elements are positioned accurately and whether content absent from the prototype has been added.

4. Gemini 3.8 Flash

FS: good search, but clearly weak form validation.

Overall CRUD performance is 51.6%, but reads at 71.2% differ substantially from editing at 35.3% and deletion at 26.0%. Read performance therefore does not establish that the entire data-operation workflow is reliable.

VS: block completeness and layout problems both matter.

Overall assessment: search, filtering, and reads are relative strengths; form rules, error feedback, editing, and deletion are the main weaknesses. Visual work must verify complete implementation of prototype blocks as well as adjust layout.

5. GPT-6 Astra

FS: strongest overall, with error feedback and write operations still weak.

VS: layout and text are the two most prominent problem categories.

Overall assessment: it ranks first in both functional and visual scores and has the best control of missing-block errors. Nevertheless, many tests for error feedback, access control, editing, and deletion still fail. Visually, prioritize calibrating layout dimensions and text content over adding blocks.

6. Doubao Seed 2.0 Pro

FS: low pass rates across multiple dimensions, especially rule validation and data changes.

VS: missing blocks are the most concentrated problem.

The low shares of image and text errors do not directly indicate higher accuracy in those areas, because missing blocks and other errors occupy a larger share.

Overall assessment: under this configuration, functional failures are widespread. Prioritize form validation, data changes, state synchronization, and permission restrictions. Visually, first check block completeness, followed by layout and navigation structure.

Appendix A: Interactive dashboard