Can I share a Percy build with someone who doesn't have an account?

Not the build itself — Percy builds sit behind BrowserStack authentication and a project seat. To get a diff in front of a designer or PM who has neither, publish the snapshot images as a page and share that URL.

Why does visual review stall on access?

Because the people best placed to judge a visual change are usually the ones without CI seats. A design lead who has to request access, get provisioned, and learn Percy's UI will instead reply 'looks fine' without looking.

What should the published page contain?

Only the snapshots that changed, each with before, after and the diff, plus the PR link and one line of context. A page with 400 unchanged snapshots gets closed.

Can reviewers approve from the published page?

Approval still happens in Percy — that is the system of record. The published page is where the discussion happens, so the person who clicks approve does it knowing what everyone thought.

Does this work from CI?

Yes. After `percy exec`, pull the changed snapshots from the API and publish them in the same job.

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.
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:

<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 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. 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 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.

Try it

Free — unlimited reports, commenters and revisions.

Publish from CI →