# Visual QA Diff Process for Resolving Pixel Discrepancies in AI Website Cloning > Master the visual QA diff process to resolve pixel discrepancies in AI website cloning. Ensure pixel-perfect fidelity by comparing original and cloned sites for exact CSS value matches. - Repository: [JCodesMore/ai-website-cloner-template](https://github.com/JCodesMore/ai-website-cloner-template) - Tags: how-to-guide - Published: 2026-07-07 --- **The visual QA diff process validates pixel-perfect fidelity by comparing side-by-side screenshots of the original and cloned sites at identical viewports, then iterating through section-by-section analysis until all CSS values match the component specifications exactly.** The **JCodesMore/ai-website-cloner-template** repository implements a rigorous **visual QA diff process** as the final gate in its Assembly & QA pipeline. Defined in [`.windsurf/workflows/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.windsurf/workflows/clone-website.md) under Phase 5 and referenced in the [`README.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/README.md) Assembly & QA section, this workflow treats visual validation as a behavioral specification rather than a one-off screenshot check. By systematically isolating pixel deviations and tracing them back to either extraction errors or implementation flaws, the process ensures that cloned websites achieve 1:1 visual fidelity with their source counterparts. ## Phase 5: The Visual QA Diff Workflow The workflow begins immediately after component assembly, when the builder generates a complete preview of the cloned site. At this stage, the system captures reference screenshots and initiates a structured comparison protocol. ### Side-by-Side Screenshot Comparison The process requires opening both the original URL and the local clone simultaneously at standardized viewport widths. The workflow specifies **desktop 1440px** and **mobile 390px** as the canonical breakpoints for comparison. Screenshots are saved to `docs/design-references/` and arranged side-by-side for immediate visual inspection. This dual-viewport approach ensures that responsive layouts, not just static desktop views, maintain pixel-perfect alignment. ### Section-by-Section Analysis Rather than comparing entire pages as monolithic images, the QA process operates **top-to-bottom**, matching each original section with its counterpart in the clone. This granular methodology isolates the exact region where a pixel discrepancy appears, preventing minor offset issues in one component from obscuring errors in adjacent elements. The comparison focuses on spacing, typography, color values, and positioning relative to the viewport edges. ## Resolving Pixel Discrepancies Step-by-Step When the side-by-side comparison reveals a visual deviation, the workflow follows a deterministic resolution path that distinguishes between data errors and implementation errors. ### Identifying the Root Cause For any mismatched pixel, the corresponding **component specification file** at `docs/research/components/.spec.md` serves as the source of truth. These specifications contain the **exact CSS values** obtained from `getComputedStyle()` during the extraction phase. If the spec value does not match the original site, the extraction must be re-run using the browser MCP to update the reference data. If the spec is correct, the discrepancy lies in the builder's implementation. ### Implementing Component Fixes When the specification validates correctly but the visual output differs, the builder adjusts the implementation to reflect the recorded values. Typical corrections include: - Updating miss-typed color hex codes, spacing values, or font sizes - Adding missing hover, focus, or scroll-triggered state definitions - Correcting responsive breakpoint thresholds or z-index layering for images ### Iterative Verification After implementing fixes, the developer rebuilds the project and repeats the visual comparison: ```bash # Rebuild the application after component corrections npm run build # Launch the development server for live comparison npm run dev # Open both the original URL and localhost side-by-side # Use PixelSnap or browser dev tools to highlight pixel offsets ``` Steps 1-4 are iterated until **no pixel differences remain** between the original and the clone. ## Capturing State Transitions and Dynamic Behaviors The visual QA diff process extends beyond static screenshots to validate interactive behaviors. The workflow explicitly requires testing scroll-triggered transformations, hover states, and click interactions to ensure dynamic pixel-perfect matches. The following pattern demonstrates how to record before/after CSS values for state transitions: ```javascript // Capture before/after styles for a scroll-triggered header // Step 1 – capture initial state (scroll = 0) const before = getComputedStyle(document.querySelector('header')); // Step 2 – trigger scroll change via browser MCP window.scrollTo(0, 120); // Step 3 – capture after state const after = getComputedStyle(document.querySelector('header')); // Step 4 – record the diff in the spec /* Property | Before | After | Transition --------------------------------------------------------- background | rgba(255,0) | rgba(0,255) | all 0.3s ease height | 80px | 60px | height 0.3s ease */ ``` This explicit recording of **before/after CSS values** and **transition details** ensures that animations and state changes maintain the same timing and visual properties as the original site. ## Summary The **visual QA diff process** in the AI website cloner template ensures pixel-perfect fidelity through systematic verification: - **Side-by-side comparison** at 1440px and 390px viewports isolates discrepancies across device types - **Section-by-section analysis** pinpoints exact locations of pixel deviations without noise from adjacent components - **Spec cross-referencing** against `docs/research/components/.spec.md` files distinguishes extraction errors from implementation bugs - **Iterative rebuild cycles** (`npm run build`) continue until zero visual differences remain - **Interactive verification** validates scroll, hover, and click states using recorded `getComputedStyle()` values ## Frequently Asked Questions ### What viewport sizes are used for the visual QA diff process? The workflow mandates testing at **desktop 1440px** and **mobile 390px** widths. These specific breakpoints ensure that both expansive desktop layouts and constrained mobile interfaces maintain 1:1 visual fidelity with the original source site. ### How does the process handle interactive states like hover and scroll? The QA process captures **before and after CSS values** using `getComputedStyle()` for all interactive transitions. Developers trigger state changes via the browser MCP, record the computed values, and verify that the clone reproduces identical timing functions and property values as documented in the component spec files. ### Where are the CSS reference values stored for comparison? Exact CSS values are stored in `docs/research/components/.spec.md` files. These specifications serve as the immutable reference during the visual QA diff process, containing values extracted directly from the original site using `getComputedStyle()` during the research phase. ### What commands trigger the rebuild after fixing a component? After correcting implementation errors, developers run `npm run build` to compile the application and `npm run dev` to launch the development server. The visual comparison is then repeated against the original URL until the side-by-side analysis shows zero pixel discrepancies.