The edit nobody documented
Here's a situation that comes up more than you'd think. You have a Make.com scenario that's been running fine for months. You make what feels like a small change, maybe adjusting a filter condition or swapping a field mapping. You test it, it looks fine, you move on.
Two days later, someone notices the scenario is producing wrong results. You go back in to investigate and realize you genuinely cannot remember what you changed. Was it the filter? The mapper? Did you accidentally remove a module? Is the version running now even the one you tested?
Make.com doesn't have version history. There's no git blame, no diff view, no audit log that shows you what changed between two points in time. Once you save a scenario, the previous version is gone unless you exported it before making the edit.
That's why we built the Blueprint Diff tool. It takes two exported blueprints and tells you exactly what changed between them: which modules were added, which were removed, which were modified, and specifically which fields inside each module are different.
The habit that makes this work
To use this tool, you need two blueprints: the before and the after. That means you need to be in the habit of exporting your blueprint before making significant changes.
It's a 10-second step. Open your scenario, click the three dots in the bottom toolbar, select Export Blueprint, save the file with today's date in the name. That file is your snapshot. Now make your changes. If something goes wrong, you have something to compare against.
If you're already past that point and forgot to export before the edit, the tool still helps when someone else has the previous version (a client, a teammate, or a backup copy on your drive). And going forward, the export-before-edit habit is worth building.
How to use the Blueprint Diff tool
The process is straightforward. You bring two blueprint files, the tool does the comparison.
Export both blueprints
If you have the original saved, great. If not, export the current version now so at least you have a baseline for future comparisons. In Make, click the three dots (...) in the bottom toolbar and select Export Blueprint.
Open the Blueprint Diff tool and load both files
The tool has two input slots side by side, labeled Before and After. Drop or paste your older blueprint on the left, your newer one on the right. Each slot validates the JSON and shows a green indicator when the file is loaded correctly.
Click Compare Blueprints
The button activates once both sides have valid blueprints. Click it and the diff runs instantly in your browser.
Read the results
You'll see a summary at the top (how many modules were added, removed, or changed), then a list of every module that isn't identical between the two versions. Unchanged modules are hidden by default so you can focus on what actually changed.
What the diff actually shows you
Results are organized by type, with the most impactful changes first.
Removed
Modules that existed in the Before blueprint but are gone from the After. If you deleted a module by accident, it shows up here. The module name, ID, and where it sat in the flow are all shown.
Changed
Modules that exist in both blueprints but have differences in their configuration. Click any changed module to expand it and see a field-by-field comparison: the path of the field that changed, the old value on the left, and the new value on the right. This is where you find the edited filter condition, the swapped field mapping, the URL that got updated.
Added
Modules that didn't exist in the Before blueprint but are in the After. New modules you added during the edit.
The field changes inside each Changed module are shown as a small table: the field path (like mapper.subject or filter.conditions), the old value in red, and the new value in green. This is the level of detail that actually tells you what broke.
Sharing the diff
Once you have the results, two buttons sit at the top of the diff view.
Copy as Markdown puts the full diff report on your clipboard formatted as Markdown, with a summary line, a section for each changed module, and a table of field changes. Paste it straight into a Slack message, a Notion doc, a GitHub issue, or a client email.
Download .md saves the same report as a file named after the scenario. Useful if you want to archive what changed alongside the blueprint exports themselves.
Both are browser-only. No files are uploaded anywhere.
What it can't catch
The diff works by comparing the JSON structure of two blueprints. That comes with some real limits worth understanding.
Module matching is by ID
The tool matches modules between the two blueprints using their internal ID number. If you deleted a module and added a similar one in its place (rather than editing the original), the tool will show one Removed and one Added instead of one Changed. That's technically accurate, but it can look more dramatic than the actual change was.
It only sees structure, not behavior
The diff tells you that a field value changed from A to B. It doesn't tell you whether that change is what you intended or whether it fixes the problem you're debugging. Logic errors, wrong formulas, and incorrect mappings still require a human to evaluate.
Position changes are filtered out
Make blueprints store the x/y canvas position of every module. If you moved modules around on the canvas without changing anything functional, those position changes are intentionally ignored. The diff focuses on parameters, mapper, and filter fields, not designer metadata.
Template strings are shown as-is
If a field value contains Make's template syntax (things like {{1.id}} or {{formatDate(...)}}), the diff shows those strings as-is. It doesn't evaluate them or tell you whether the referenced data bundle changed.
When this is most useful
Something broke and you're not sure what changed
This is the main use case. If you exported a blueprint before editing and something stopped working after, load both versions and look at the Changed modules. The field that caused the regression is almost always in there.
Reviewing someone else's edits before they go live
If you work on scenarios with a team and someone hands you an updated blueprint to review, this is a much faster way to understand what they changed than opening Make and reading through the whole thing.
Client handoffs where you need to document changes
If a client asks what you changed in their scenario during a maintenance session, the Markdown export is a clean, professional answer. Much better than "I updated a filter condition and changed two field mappings."
Verifying that a scenario was restored correctly
If you had to rebuild a scenario from memory after something went wrong, you can compare your rebuilt version against a backup to confirm you got everything right.
Compare two blueprints
Export a blueprint, make a change, export again, and see exactly what's different. Or use any two versions you already have saved.
Open Blueprint Diff