# How to Share a Percy Visual Diff With Someone Without a Seat

Canonical: https://commareports.com/share-percy-report
Published: 2026-09-14

> Percy builds live behind a BrowserStack login, so designers and PMs can't approve a diff. Publish the changed snapshots as a page and send a URL.

# Share a Percy visual diff

Percy caught it: a 3px shift on the pricing page and a button that went from
`#c1442d` to something slightly wrong. The build is red, the diff is clear, and
the person who can tell you whether it is intentional is the design lead.

Who does not have a BrowserStack seat.

## Access is the bottleneck, not detection

Visual regression testing has an audience problem that unit testing does not.
A failing unit test is reviewed by the engineer who broke it. A failing visual
diff needs judgment from whoever owns the design — and that person is usually
outside CI entirely.

The usual workarounds are all bad:

- **Screenshot the diff into Slack.** A screenshot of a pixel comparison,
  recompressed by Slack. See
  [stop screenshotting reports](/stop-screenshotting-reports).
- **Request a seat.** Two days, one licence, and a tool they open twice a year.
- **Describe it in words.** "The button moved a bit." Nobody can approve that.

## Publish the changed snapshots

Percy's API exposes the snapshots for a build. Pull the ones that changed and
assemble a page:

```html
<h1>Visual diff — PR #418</h1>
<p>Checkout refactor. 3 of 212 snapshots changed.</p>

<section>
  <h2>Pricing page · Chrome 1280</h2>
  <div class="triptych">
    <figure><img src="…base.png" /><figcaption>Before</figcaption></figure>
    <figure><img src="…head.png" /><figcaption>After</figcaption></figure>
    <figure><img src="…diff.png" /><figcaption>Diff</figcaption></figure>
  </div>
</section>
```

Publish it, drop the URL in the PR, and the design lead opens a page on their
phone and tells you whether the 3px was on purpose.

## Only the changes

The discipline that makes this work is ruthless filtering. Percy runs hundreds
of snapshots; three of them changed. Publish three.

A page with every snapshot is a page nobody scrolls, and the reviewer's
attention is the scarce resource in this whole exercise — the argument behind
[context budgeting for AI reports](/agents/context-budgeting-ai-reports) applies
just as well to humans.

## Approval stays in Percy

To be clear about the division: Percy remains the system of record. Baselines
and approvals live there, because that is what gates the build.

The published page is where the *conversation* happens — anchored comments on
the specific snapshot, from people who could never have commented in Percy at
all. See [commenting on HTML](/comment-on-html). Then whoever holds the seat
clicks approve already knowing the answer.

## Worth knowing

- **Base64-inline small snapshots, link large ones.** The
  [5 MB report limit](/docs/api) is generous but full-page retina PNGs add up.
- **Put the PR link at the top.** A reviewer who wants more context should not
  have to ask for it.
- **Publish from the CI job**, right after `percy exec`, so the page exists
  before anyone asks — see [publishing from CI](/ci).

## Try it

Free — unlimited reports, commenters and revisions.

**[Publish from CI →](/ci)**

### Related

- [Share a Chromatic build](/share-chromatic-build) ·
  [Share an Applitools result](/share-applitools-report)
- [Share a BackstopJS report](/share-backstopjs-report) ·
  [Share a Storybook static build](/share-storybook-static)
- [Publish from CI](/ci) · [Commenting on HTML](/comment-on-html)