You've got two images. They should be different — or maybe they shouldn't. You need to know exactly what changed, what got fixed, or whether the second version is actually better than the first. So you open both, squint at them side by side, and convince yourself you've spotted everything.
You probably haven't.
Human vision is genuinely terrible at spotting small differences between similar images, especially when you can't see them simultaneously at the same position on screen. Our eyes have evolved to detect motion and contrast, not subtle colour shifts or 2-pixel alignment differences. And yet designers, photographers, and developers do exactly this — manually compare images — hundreds of times a week.
There are four comparison methods that actually work, each suited to a different type of difference and a different level of scrutiny. Here's how they work, when to use each one, and why your instinct to just "look at both" is almost always the wrong approach.
Before getting into methods, it helps to understand why unaided comparison fails so often.
The first problem is change blindness. When two views of an image don't appear simultaneously at the same position on screen, your brain treats each as a separate scene. It compares the overall impression — "these look similar" — rather than scanning for individual differences. Studies on change blindness show people consistently fail to notice substantial changes between images when there's even a brief visual interruption between views (like switching windows, or scrolling).
The second problem is spatial memory. If image A is in your browser on the left and image B is on the right, you're relying on memory of one to compare against the other. Memory degrades across distance. A 3px text-shadow change on a button in the top-right of image A will probably not register when you glance over to image B — especially if you're tired.
The third problem is expectation bias. If you expect the images to be identical, you'll see them as identical. If you made the edit, you'll unconsciously look at the thing you changed and miss everything else. This is why developers who write code are notoriously bad at reviewing their own code — the same principle applies to images.
Each method has a distinct strength. They're not alternatives to each other — they're tools for different jobs. Understanding what each one reveals (and what it doesn't) lets you pick the right one for the situation rather than defaulting to whichever looks most familiar.
A vertical divider sits between the two images. Drag it left to reveal more of Image B; drag it right to reveal more of Image A. Both images are spatially aligned — the same coordinates show the same regions of each image simultaneously at the edges of the divider.
The key advantage is aligned context. Because both images are stacked on top of each other (rather than placed side by side), the content is at the same position in your visual field. A building on the left side of Image A is at the same pixel position as the building in Image B. There's no eye travel involved, so spatial memory isn't a bottleneck.
The limitation: you can only inspect the area near the divider at any given moment. If you want to see both the top-left and the bottom-right at the same time, the slider can't show you both simultaneously.
The drag slider is the most visually compelling method, which is why it's the go-to for "before and after" photography showcases. When a landscape photographer wants to show how their colour grade transformed a flat RAW file, the slider presentation makes the transformation immediately visceral — you drag it yourself and experience the reveal.
For practical review work, however, the slider is best when changes are localised to a region. If you changed the sky colour in a photo and want to verify the edit, drag to the sky region, flick the slider back and forth, and the shift registers immediately. The same technique works for design changes: a button colour update, a typography change in a specific section, a crop adjustment.
Where it struggles: changes that are spread across the entire image — slight brightness shifts, a noise reduction pass, a grain filter applied globally — are harder to see in slider mode because the full transition area is only one pixel wide at any moment. For those, overlay mode performs better.
Both images displayed simultaneously in equal panels. No interaction required — both are always fully visible at the same time. The viewer's eye travels between them freely.
This is the method most people default to — and it's the least reliable for catching small differences. It works well for comparing the overall impression of two images: does the composition feel more balanced? Is the colour mood warmer? Does version B look more professional? These are gestalt-level judgments that your peripheral vision handles, and side by side supports them well.
It's the wrong tool for detail-level comparison. Any change smaller than about 5% of the image area tends to go unnoticed in side-by-side view. It's also the only method that suffers from the eye-travel problem described above.
"Side by side is for choosing. Overlay is for finding. Pixel diff is for proving. Slider is for showing."
Use side by side when you're making a decision between two options rather than auditing for differences. Which version of the banner looks better? Which crop feels more natural? These are preference questions that benefit from seeing both at once, not precision questions about what changed.
It's also genuinely useful for composition analysis. If you're comparing a portrait taken at f/1.8 versus f/5.6, you want to see both backgrounds simultaneously to judge the depth-of-field character. The slider would make that comparison awkward because you'd be constantly switching views rather than holding both in mind at once.
Image B sits on top of Image A with adjustable opacity. Drag from 0% (fully A) to 100% (fully B). Elements that are identical between the two images look stable as you fade — they don't appear to change. Elements that are different will visibly shift, flicker, or ghost as you move the slider, drawing the eye immediately.
This is the most effective method for detecting subtle, globally-distributed changes. A slight exposure adjustment, a colour balance shift, a noise reduction pass, a small sharpening change — all of these affect the image uniformly and are invisible in a slider or side-by-side view. In overlay mode, you'll see the whole image shift slightly as you cross the midpoint of the fade, immediately flagging that something changed everywhere.
It's also the best method for catching alignment differences. Two versions of a logo where one has been accidentally shifted 3 pixels left will show a clear ghosting effect in overlay mode — the logo appears to split into two.
The trick with overlay mode is in the technique. Don't just drag the slider slowly from one end to the other. Instead, flick it rapidly between about 40% and 60%. This creates a rapid alternation that mimics the "flicker" technique used by astronomers to detect moving stars — your eye is exquisitely sensitive to motion, and the flickering of changed regions creates an immediately noticeable visual event.
At exactly 50% opacity, where both images contribute equally, misaligned or changed elements create a transparent double-exposure effect that's useful for confirming alignment on things like registration marks, text placement, or repeated UI elements across two design versions.
Every pixel in both images is compared mathematically. The RGB values are subtracted, the absolute difference is averaged across channels, and the result is rendered as a colour heatmap: grey for identical pixels, cyan for small differences, orange for moderate differences, red for large differences. Quantitative stats — percentage of changed pixels, average colour delta — are computed alongside.
This is the only method that is objective and complete. The other three methods rely on your visual perception — they can miss things. Pixel diff catches everything and provides numbers. A pixel diff with 0.3% changed pixels and an average delta of 1.8 tells you something very specific: nearly identical, with tiny differences consistent with JPEG re-encoding. A diff with 42% changed pixels and an average delta of 38 tells you there are substantial differences across almost half the image.
The limitation is context. A pixel diff shows you where and how much things changed, but not why or whether it matters. Two screenshots of the same webpage taken with different anti-aliasing settings will produce a noisy diff even though the content is functionally identical. Pixel diff needs interpretation.
Pixel diff has become the backbone of automated visual testing in software development. Tools like Percy, Chromatic, and Playwright's screenshot comparison all use pixel diff under the hood: they capture a screenshot, compare it to an approved baseline, and flag any pixel-level deviations above a threshold. This catches UI regressions that would never be noticed in manual review — a button that's 1px too wide after a CSS refactor, a font that's rendering slightly differently after a dependency update.
For designers working without automated pipelines, pixel diff is most useful when you want to document what changed between versions, or when you need to verify that a supposedly "identical" re-export is actually identical. Saving a file from Photoshop vs. Lightroom vs. Affinity Photo produces subtly different pixels even at the same quality setting — pixel diff makes that difference concrete and measurable.
| Situation | Best method | Why |
|---|---|---|
| Client approval presentation | Slider | Compelling visual reveal, works well in screen share or recorded walkthrough |
| Finding a subtle colour grade change | Overlay | Global changes cause visible flicker across the whole image as you fade |
| Choosing between two versions | Side by Side | Gestalt impression of both at once, no interaction overhead |
| Checking alignment after a move | Overlay | Misaligned elements ghost visibly at 50% opacity |
| Verifying a resave hasn't lost quality | Pixel Diff | Exact quantitative comparison — shows changed px count and average delta |
| Reviewing a photo retouch | Slider | Both before and after at aligned coordinates, easy to scan regions |
| Visual regression in a UI screenshot | Pixel Diff | Catches 1px changes and provides documented evidence of what changed |
| Comparing noise reduction results | Overlay + Pixel Diff | Overlay shows the visual feel; diff shows the extent of pixel modification |
| Comparing two entirely different images | Side by Side | No alignment assumed; just a clear simultaneous view of both |
| Documenting approved design changes | Pixel Diff | The heatmap and stats provide objective, shareable evidence of what changed |
Overlay at 50% opacity is the fastest way to spot any difference at all. Once you've seen something flicker, switch to slider mode and position the divider over that region for a closer look at the aligned detail.
Run a pixel diff on the final version pair as the last step. It will often catch one small region you missed in visual inspection — a corner, a shadow edge, a semi-transparent element. This is especially useful before sending work to print or handing off to a developer.
Rapid alternation between ~40% and ~60% opacity exploits the eye's motion-detection sensitivity. Changed areas will appear to "shake" or "breathe" in a way that smooth dragging doesn't produce. This works particularly well for detecting alignment shifts of a few pixels.
A 0.1% diff with average delta of 1.2 almost certainly means JPEG re-encoding noise — probably nothing visible. A 5% diff with average delta of 45 means visible, substantial changes covering a meaningful region. The percentage alone doesn't tell you whether the changes are perceptible — the combination of percentage and delta does.
The pixel diff heatmap is a document of record. Save it alongside your version files. When a client or stakeholder asks "what changed between version 2 and version 3?", showing a diff heatmap is faster and more precise than describing the changes in words.
A difference that's visually significant at 100% zoom might be completely imperceptible when the image is displayed at its intended size. Compare images at the size they'll actually appear — thumbnail-sized images don't need to be pixel-perfect at 1:1, they need to be visually clear at the display size that matters.
The most common use case. Comparing a RAW export to a colour-graded version, checking whether a retouching pass is convincing at actual print size, reviewing whether a batch edit applied correctly to a set of images. The slider is the showpiece method here — it's what photographers use in tutorials and client presentations because the reveal is immediate and visceral. But for actual accuracy checking, the overlay flicker method catches more.
A specific workflow: after finishing an edit, export both the original and the edited version at final size. Use overlay mode to scan for any accidental damage — artefacts introduced by a tool, halos from over-sharpening, colour banding from a gradient adjustment. These tend to appear as localised flickers in overlay mode, pointing straight to the problem area.
Designers comparing two versions of a screen mockup most often want to answer: did my change look the way I intended, and did it break anything else? The slider is good for inspecting specific components. The pixel diff is good for checking whether a "no-change" version has unexpectedly drifted — a rendering engine update, a font substitution, a line-height rounding difference.
Frontend developers use automated pixel diff tools as part of their CI pipeline, but visual comparison tools are still useful for ad-hoc checks: comparing how a page renders in Chrome versus Firefox, comparing desktop and mobile screenshots at scaled dimensions, or verifying that a CSS refactor didn't change any visible output.
Comparing a digital proof to the final print scan, or comparing two press runs for consistency. In this context, pixel diff is particularly useful because print quality control involves actual numbers: colour delta values (which relate directly to ΔE colour difference), percentage area coverage, and registration accuracy. The diff heatmap maps directly to how printers think about quality — which regions exceeded acceptable deviation?
Technical illustrations, architectural diagrams, data visualisations. When a CAD drawing gets revised, a chart gets updated, or a schematic changes, the visual comparison question is: what moved, what was added, what was removed? The slider and side-by-side methods work well here. The pixel diff will produce large changed regions wherever labels or dimensions moved, which can be hard to interpret unless you know that all the changes were intentional.