pixelpact

io.github.jamalkamaladdinPublished by GitHub account jamalkamaladdinv0.1.6Updated Oct 27, 2026

Extract a visual contract from a reference page and measure an implementation against it

Overview

AI-generated overview

Measures a built web page against a reference design's extracted visual contract and returns per-property deviations, so a coding agent can check its own UI…

What you can do
  • Extract a visual contract from a reference page: sizes, colors, spacing, typography, hover and focus states, keyframes and design tokens
  • Check an implementation against a contract and get one line per drifted property with expected, actual and difference
  • Compare screenshots pixel by pixel and report a percentage difference
  • Read a summary of a stored contract
When to use it
Useful when an agent is writing CSS or UI code toward a reference design and needs numbers to close the loop instead of a person eyeballing the page. Also fits teams that want objective measurements of a section before calling it finished.
Requirements
Runs locally over stdio via npx pixelpact-mcp. Needs Node 22.12 or newer and Playwright with Chromium installed as a peer dependency. A contract must be extracted first. Reading a Figma frame instead of a URL requires the FIGMA_TOKEN environment variable.
Before you install
The server drives a real browser against pages you point it at, so only target URLs you trust. Figma extraction sends the frame request to Figma's REST API using FIGMA_TOKEN. A passing check only covers values present in the contract; extra elements on your page are not flagged unless a pixel diff is also run.

Installation

In SourceWeft

  1. Open pixelpact in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[pixelpact]

Your coding agent cannot see the page it just built. pixelpact measures it against the reference and hands back numbers.

[CI] [npm] [node] [license]

A coding agent writes the CSS and says it is done. It never sees the result. Nothing hands it a number, so the loop cannot close: the agent guesses, you open the page, you send it back, it guesses again. Every round costs you the one thing the agent was supposed to save.

The same gap exists without an agent, when a teammate says a section is finished and nobody in the room has a measurement. The difference is that a person can at least look.

pixelpact reads the reference page and writes down what it actually renders: sizes, colors, spacing, typography, hover and focus states, animation keyframes, design tokens. That file is the contract. Point pixelpact at the implementation and it answers with one line per property that drifted, which is precisely what an agent can act on.

bash
npx pixelpact extract https://reference.example.com -o contract.jsonnpx pixelpact check contract.json http://localhost:3000

Works with

MCP clientsPlaywrightGitHub ActionsAny frameworkFigma
Claude Code, Cursor, anything that speaks stdio MCPthe engine it drivesone comment on the pull requestit reads the DOM, not your stacka frame as the reference, when you want one

If a browser can render it, pixelpact can measure it.

For coding agents

An agent that writes UI code cannot tell whether it succeeded. pixelpact-mcp gives it the measurement, so the loop closes without a person in the middle: extract the contract once, then let the agent check its own work, read the deviation list, fix, and check again.

jsonc
// .mcp.json{  "mcpServers": {    "pixelpact": { "command": "npx", "args": ["-y", "pixelpact-mcp"] }  }}

Tools exposed: extract_contract, check_implementation, diff_pixels, read_contract_summary.

Why this is not visual regression testing

Percy, Chromatic, Applitools, BackstopJS and Pixeleye all compare your page against a baseline that you approved earlier. That model works once the page already looks right and you want to keep it that way. While you are still building toward a design, there is no baseline to compare with, and the first run of a regression tool simply records whatever you produced.

Visual regression toolspixelpact
Compares againsta snapshot you approved earlierthe reference design itself
Useful whenthe UI is already correctthe UI is being built
First run on a new pagerecords, cannot judgemeasures against the reference
Answer you getan image diff to inspect by eyea value per property, with a delta
Fits an autonomous agentneeds a human to approve the diffthe numbers close the loop

The two models are complementary. Use a regression tool to keep a finished page finished, and pixelpact to get it finished in the first place.

Problems pixelpact solves

Without pixelpactWith pixelpact
❌ A coding agent writes CSS, declares it done, and a person has to open the page to find out that it is not.✅ The agent calls the MCP server, reads the deviations, fixes them and checks again. No person in the middle.
❌ Someone says the section is finished, you disagree, and neither of you has a number. The louder opinion wins.✅ Every value in the reference is asserted against your page. What failed is listed with expected, actual and the difference.
❌ A regression tool has nothing to compare a brand new page against, so its first run records whatever you happened to build.✅ The reference is the baseline from the first minute. Nothing has to be approved before the tool is useful.
❌ Hover, focus and animation values are almost never reviewed, because checking them by hand is slow and boring.✅ They are part of the contract, so they are measured on every run like any other value.
❌ An image diff tells you that something changed and leaves you to hunt for what.✅ Deviations name the element, the property, the expected value and the measured one.
❌ The design lives in a file nobody opens during code review.✅ The contract is committed JSON, so a pull request shows exactly which values moved.

Install

bash
pnpm add -D pixelpact playwrightpnpm exec playwright install chromium

playwright is a peer dependency, so the browser download stays under your control and a project that already has Playwright installs nothing extra. Node 22.12 or newer is required.

Quickstart

1. Extract the contract from the reference.

bash
npx pixelpact extract https://reference.example.com \  --selector "main" \  --viewport desktop,mobile \  --screenshots .pixelpact/shots \  -o contract.json

2. Measure your implementation.

bash
npx pixelpact check contract.json http://localhost:3000 --viewport desktop

3. Fix what it reports, then run it again. The command exits 0 when everything is inside tolerance and 1 when it is not, so it drops straight into a script or a CI job.

What a contract looks like

A contract is plain JSON, readable and diffable, with no proprietary format and no service behind it.

jsonc
{  "version": 1,  "source": { "type": "url", "value": "https://reference.example.com" },  "root": "main",  "extractedAt": "2026-09-06T01:20:44.812Z",  "viewports": [{ "name": "desktop", "width": 1440, "height": 900 }],  "tokens": { "--brand-600": "rgb(11, 114, 133)" },  "keyframes": { "fade-up": [{ "offset": "0%", "css": "opacity: 0" }] },  "byViewport": {    "desktop": {      "documentHeight": 4218,      "elements": [        {          "selector": "main > header > a.cta",          "tag": "a",          "text": "Get started",          "box": { "x": 120, "y": 32, "w": 148, "h": 44 },          "styles": {            "background-color": "rgb(11, 114, 133)",            "font-size": "16px",            "border-radius": "8px"          },          "hover": { "background-color": "rgb(8, 90, 105)" },          "focus": { "outline": "2px solid rgb(11, 114, 133)" }        }      ]    }  }}

Because it is a file, you can commit it, review it in a pull request, hand it to another developer, or hand it to an agent.

What a check prints

text
pixelpact check  FAILED  target    http://localhost:4173/impl.html  reference http://localhost:4173/ref.html  viewport  desktop 1440x900  elements  14 matched, 0 missing of 14  checks    1056 passed, 10 failed (99.1% of 1066)
deviations (10)SELECTOR          PROPERTY                  EXPECTED                ACTUAL                  DIFFbody > main > h1  font-size                 48px                    44px                    4pxbody > main > a   box.width                 117.75px                109.75px                8pxbody > main > a   padding-right             24px                    20px                    4pxbody > main > a   padding-left              24px                    20px                    4pxbody > main > a   background-color          rgb(11, 114, 133)       rgb(37, 99, 235)        60.1 (color)body > main > a   border-top-left-radius    8px                     4px                     4pxbody > main > a   border-top-right-radius   8px                     4px                     4pxbody > main > a   border-bottom-left-ra...  8px                     4px                     4pxbody > main > a   border-bottom-right-r...  8px                     4px                     4pxbody > main > a   focus.outline             rgb(11, 114, 133) s...  rgb(37, 99, 235) so...  differs

That is a real run against two copies of one page with four declarations changed. Four edits produce ten measured deviations, because padding moves the box width and one border-radius shorthand sets four corners. Run the same check against the reference itself and all 1066 assertions pass, which is the property that matters: a passing check has to mean something.

Add --json to get the same report as a data structure, which is what CI jobs and agents read.

What a side by side run shows

check says which values moved. diff says how many pixels moved. Neither tells a person where to look. side splits both pages into sections, puts them next to each other, and boxes what differs.

bash
npx pixelpact side https://reference.example.com http://localhost:3000 --widths 1440,390
text
#   SECTION   WIDTH   VERDICT  DIFF01  hero      1440px  PASS     0.000%02  features  1440px  FAIL     0.675%  .pixelpact/side/1440/02-features.png03  pricing   1440px  PASS     0.000%04  foot      1440px  FAIL     1.265%  .pixelpact/side/1440/04-foot.png

[One section compared side by side, differences boxed in red]

That is a real run against the two files in examples/side, which are copies of one page where the card gap and the corner radius were changed. Reproduce it with:

bash
npx pixelpact side "file://$PWD/examples/side/reference.html" \                   "file://$PWD/examples/side/implementation.html" --widths 1440

This is the command to run before telling anyone that a page is finished.

Features

Contract from the reference

Reads the page you are building toward and writes down every value it renders. Nothing to approve first.
Numbers, not opinions

Each deviation carries the expected value, the measured value and the difference between them.
States, not just layout

Interactive elements are hovered and focused, and only the properties that actually change are stored.
Tokens and keyframes

Custom properties on the root element and named animation keyframes travel inside the contract.
Pixel comparison

When every value passes and it still looks wrong, compare the screenshots and get a percentage.
Agent ready

An MCP server exposes the same measurements, so a coding agent can close its own loop.
Pull request checks

A composite Action runs the check and keeps one comment on the pull request up to date.
Plain JSON

The contract is a file you can read, diff and review. No service, no account, nothing to log into.
Framework agnostic

It measures the rendered DOM, so React, Vue, Svelte and hand written HTML are all the same to it.

Commands

CommandWhat it does
pixelpact extract <url>Reads the reference and writes a contract file
pixelpact check <contract> <url>Measures an implementation, prints deviations, sets exit code
pixelpact diff <contract> <url>Pixel comparison against the screenshot stored in the contract
pixelpact side <reference> <url>Section by section side by side images with the differences boxed

Shared flags cover the browser context (--viewport, --selector, --wait, --timeout, --locale, --timezone, --channel, --headful), the output (--out, --json, --quiet), and the parts of extraction you may want to cap (--max-elements, --max-states, --mask). Run pixelpact <command> --help for the full list.

Exit codes

CodeMeaning
0Everything inside tolerance
1Deviations found, or the pixel threshold was exceeded
2Usage error, for example a bad flag or a contract file that is missing
3Runtime failure, for example no browser available or the page would not load

Programmatic use

ts
import { extract, check, formatCheckReport, writeContract } from 'pixelpact-core'
const contract = await extract({  url: 'https://reference.example.com',  selector: 'main',  screenshotDir: '.pixelpact/shots',})await writeContract('contract.json', contract)
const report = await check(contract, { url: 'http://localhost:3000' })
console.log(formatCheckReport(report, { color: true }))if (!report.ok) process.exitCode = 1

Everything is typed, and the contract and report shapes are validated at the boundary, so a malformed file fails with a readable message instead of a stack trace.

In CI

The Action measures a preview deployment against the contract committed in the repository and keeps a single pull request comment up to date instead of adding one per push.

yaml
- uses: jamalkamaladdin/pixelpact/action@v0  with:    contract: contract.json    url: ${{ steps.preview.outputs.url }}    viewport: desktop    tolerance: 1

It needs permissions: pull-requests: write and no secret beyond the automatic GITHUB_TOKEN. Every input, every output and a complete workflow are in action/README.md.

Reading a Figma frame

extract recognises a Figma url and reads the frame through the REST API. No browser is launched for this step.

bash
export FIGMA_TOKEN=figd_...npx pixelpact extract "https://www.figma.com/design/KEY/Name?node-id=12-345" -o contract.jsonnpx pixelpact check contract.json http://localhost:3000

A Figma layer has no CSS selector, so a Figma contract binds to your markup through data-contract attributes. Name the element after the layer and matching stops depending on how the design happened to nest its frames:

html
<a class="btn btn-primary" data-contract="Hero/CTA">Get started</a>

Anything with no match is reported as missing rather than guessed from tag names.

Published styles come across as tokens: a color style as its color, a text style as a css font shorthand such as 600 60px/72px Geist, an effect style as a box shadow. A fill that is a gradient or an image has no single css value, so it is left out and named in the warnings rather than approximated.

How it works

  1. Playwright opens the reference at each requested viewport, waits for fonts, network and paint to settle, and dismisses cookie overlays.
  2. A single function is evaluated inside the page. It walks the DOM under your root selector and records the computed style of every visible element, plus custom properties, keyframes, and the geometry of each box.
  3. Interactive elements are hovered and focused, and only the properties that actually change are stored, so a contract stays small enough to read.
  4. Checking repeats step 2 against your implementation, matches elements by data-contract attribute, then by selector, then by tag and text, and compares property by property. Lengths use a pixel tolerance, colors use a perceptual distance, and animations are compared by name and timing rather than by string equality.

Repository layout

PackagePublished asWhat it is
packages/corepixelpact-coreExtraction, checking, reporting
packages/clipixelpactThe pixelpact command
packages/mcppixelpact-mcpMCP server for coding agents
actionused from GitHubAction for pull request checks

FAQ

How does an agent use it? Install pixelpact-mcp, point the MCP client at it, extract the contract once, then let the agent call check_implementation after every edit and read the deviation table it gets back.

How is this different from Percy or Chromatic? They compare your page against a snapshot you approved earlier, which assumes the page is already right. pixelpact compares it against the reference, which is what you actually have while you are still building. The two fit together: pixelpact to get the page correct, a regression tool to keep it that way.

Do I need a baseline? No. The reference is the baseline, and that is the entire point.

My markup does not match the reference structure. Will anything match? Element matching tries the data-contract attribute first, then the selector, then the tag and its text. Put data-contract="hero-cta" on your element and matching stops depending on how the reference happened to nest its divs.

The page has content that changes on every load. Will a check ever pass? Mask it. --mask ".carousel" keeps a region out of the pixel comparison, and --max-elements stops a long page from producing a contract nobody can read.

Which browsers? Chromium through Playwright. Running a matrix across engines is out of scope on purpose: this tool measures agreement with a design, not differences between browsers.

Does a passing check mean the page is correct? It means every value in the contract matched inside tolerance. Elements that exist in your page but not in the reference are not flagged, because the contract only describes what the reference contains. Run diff as well when nothing extra is allowed.

Status

Everything described above is built and every number shown came from a real run: extraction from a live page and from Figma, checking, the pixel diff, the side by side images, the MCP server and the Action.

Version 0.3. Settled enough to use, not settled enough to promise: the contract format will gain fields before 1.0. If a value you need is missing from it, open an issue and say which one, because that is the fastest way for it to appear.

Contributing

Development setup, the commands, and the pull request flow are in CONTRIBUTING.md. Security reports go through SECURITY.md.

License

MIT © Jamal Kamaladdin

Source: README.md at commit fd7387f

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.6LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts