Features
Catch visual and accessibility changes before they merge
Framecheck checks the component examples in your Storybook, compares screenshots with your team’s approved version and reports results on GitHub. Start with the changes that matter, then explore the details.
Try reviewing a sample change · No account needed; changes affect only your demo.
Catch changes
Spot unexpected layouts and common accessibility problems before they reach customers.
Visual diffs
Each story is compared with the accepted baseline, pixel by pixel. You see exactly what changed and how much.
- Side by side, highlighted diff or overlay, with zoom
- A change in size always counts as a change
- Keyboard shortcuts to move through changes and accept or reject them
Repeatable capture across browsers
Choose Chromium, Firefox and WebKit, captured in pinned versions with fixed viewports, locale and time zone. It is designed to give the same screenshot for the same code, and a story that keeps changing between captures is flagged as unstable.
- Animations off; Framecheck waits for fonts, images and network requests, then checks the page has stopped changing
- Requests to other sites are blocked unless you allow them, and the blocked sites are listed
- Storybook viewports and modes are supported
- Set permitted external hosts, viewports, locale and time zone per project; bundle fonts and fixture data with your Storybook
Accessibility checks
Turn on accessibility checks for a project and every story is scanned with axe-core in the same run as its screenshot.
- WCAG 2.2 level A and AA rules, including same-origin iframes
- Results the rules cannot decide are listed as “needs review”, never counted as a pass
- Findings have their own baseline, so pull requests show new and worsened issues
- Automated checks find common problems, not all of them. They are not a compliance certificate.
Flaky-story quarantine
Set aside a story that keeps changing, by hand or automatically once you turn it on. It is shown separately and never fails the check or holds up the baseline.
Ignore regions
Mark the parts of a story that are meant to change, such as dates or avatars, and those pixels are left out of the comparison. Chromatic-compatible markers (.chromatic-ignore, data-chromatic="ignore" and ignoreSelectors) work as they are.
Accessibility trends and CSV export
See how accessibility issues on your default branch change over time, by severity and by rule. Download the trend, or any run’s findings, as CSV.
Review with your team
Accept an intended change, or fix an unexpected one in your code and run the checks again.
Baselines and approvals
The baseline is the set of snapshots accepted on your default branch. Pull requests are compared with the baseline at their merge base.
- Approvals are tied to the exact images a reviewer saw
- Accepting a change on a pull request never changes the baseline
- The baseline moves once the change is merged and its run on the default branch is accepted
Open the story behind the screenshot
Switch to Live to interact with a supported story while you review, or open the uploaded Storybook to explore the build. Links require access to the project.
- Live helps investigate a change; the captured screenshots determine the review outcome
- Availability depends on the retained build and supported story settings
- This is separate from publishing Storybook on a custom domain
Inspect page structure
For changed stories, compare the recorded, redacted HTML structure behind the screenshots to help explain a change.
- On by default; admins can turn it off and stories can opt out
- Shown as text, not executed HTML
- Advisory context: screenshot comparisons still decide the result
- Older snapshots may not have recorded structure
Approvals carried forward
When a new commit produces images you have already approved, the approval carries over. Changes accepted on a pull request carry through to the default branch after the merge.
Review comments and reviewers
Comment on a specific snapshot, assign reviewers and ask for changes before a pull request passes.
Fit your workflow
Connect the review to your existing GitHub pull requests and team permissions.
GitHub checks and PR policies
Every pull request gets a GitHub check with the result. You decide what the check requires.
- Report only, require approval for changes, or fail on any difference
- Set a company default and override it per project
- The policy in force when a run starts is recorded with that run
Roles and audit log
Viewer, member and admin roles apply across your company, and admins can see a log of administrative changes.
- Viewers can look; members review; admins manage settings, members and billing
- A company always keeps at least one admin
One-click GitHub Actions setup
Framecheck opens a pull request that adds its GitHub Actions workflow, set up the way your repository already builds Storybook. Copy the project’s upload token and add it as a repository secret; we link you straight to the GitHub page. Rotate it any time without downtime.
Choose when Framecheck runs
Leave out pull requests by author (such as Dependabot), branch, label or draft status. They get a neutral check that never blocks merging.
Notifications
Hear when a build needs review or fails: a pull request comment that updates in place, webhooks and an email digest.
Smart Snapshots, included on every plan
Pull requests capture only the stories a change could affect. Every other story is shown as unchanged with its approved baseline image, so runs finish sooner. Framecheck leaves a story uncaptured only when it can prove the change cannot affect it; anything uncertain captures every story, and your default branch always captures every story. Every story checked is billed as one snapshot, captured or unchanged.
Email sign-in and two-factor authentication
Sign up and sign in with your email address and a password, invite teammates by email, and protect accounts with an authenticator app.
Try it on your own Storybook
Compare the Starter trial, Starter and Pro plans. See pricing