The method is published. The numbers are not in yet, and that order is deliberate. Anyone can run a benchmark and report the result that suits them. We are publishing the scoring criteria first, in public, so we cannot quietly adjust them once we see how we score. When the results land they will appear here with the source design, every tool's raw output, and our own scores alongside the rest.
Why this exists
Every tool in this category claims pixel accuracy. Nobody publishes how they measured it, which makes the claim unfalsifiable and therefore worthless to someone trying to choose.
So we are publishing the method first, before we have results, so that the method cannot be quietly adjusted afterwards to flatter us.
The method
One source design. A single screen, containing the things that actually break in generated code rather than the things that demo well: absolute placement, a corner radius, a gradient fill at a non-obvious angle, a text block with specific line height and letter spacing, a multiline input, and enough content to require scrolling.
Same design for every tool. Where a tool needs a Figma file as input, it gets a Figma file built to the same specification. Where a tool has its own canvas, the design is rebuilt on that canvas. This is a real asymmetry and we will describe exactly what was done for each tool rather than pretending the inputs were identical.
Export with default settings. No hand-tuning, no cleanup pass, no picking the best of several attempts. Whatever the tool produces on a straightforward run is what gets scored.
Score on four axes:
- Static placement. Do elements land at the specified coordinates and sizes?
- Style accuracy. Colours, radii, gradient angle, typography metrics.
- Behavior. Does the multiline field grow and push content down? Does scrolling reach the true bottom?
- Does it build? Does the output compile or run without edits.
Publish everything. Source design, every tool's raw output, the diffs, and the scoring. If a result is contested, the evidence is there to check.
What we will report about ourselves
The same four axes, scored the same way, including where we lose.
We already know one of those: our output is not responsive, so any axis measuring adaptation to different viewport widths would score us at zero. We are not adding an axis we would fail and then omitting it, and we are not adding one we would win on that does not matter to buyers. The four axes above are fixed as published.
What this benchmark will not tell you
Whether the code is pleasant to maintain. Our output is absolutely positioned, which is exact and not idiomatic, and a fidelity score says nothing about how it feels to live in that codebase for a year. That is a real evaluation criterion and this benchmark does not measure it.
When
When the comparison is done. We are not going to rush it: a fidelity benchmark that is quick to produce is one nobody should trust, and the criteria above are already fixed, so there is nothing to gain by hurrying.