This tool diffs two schema versions field by field. You paste the old field list and the new one, and the tool reports added fields, removed fields, and unchanged fields. Schema drift — columns renamed, dropped, or added between data versions — is a leading cause of broken pipelines and silent analysis errors: code that reads a removed column fails loudly if you are lucky, and quietly reads the wrong column if you are not. A diff before merging a new version turns drift into a visible, reviewable change instead of a surprise discovered in results.
How to use it
- Paste the old version’s fields, comma-separated.
- Paste the new version’s fields.
- Click Diff schemas.
- Review removed fields first: each is a potential breaking change.
- Check downstream code and dashboards for every removed or renamed field.
Worked example
Version 1 of a survey export has id, name, age, city. Version 2 has id, name, age, email, country. The diff shows email added, city removed, and country added — and the removal is the story: every dashboard filtering by city breaks, and the “country” field is not a rename of “city” but a coarser geography that changes what regional analysis can claim. The team renames the export back to include city alongside country, preserving both the old analysis and the new field. One diff, one avoided breakage, one preserved comparison over time.
Honest limits
The tool compares field names only: it cannot detect type changes (age from integer to text), meaning changes (city now meaning metro area instead of municipality), or renamed fields (it reports a rename as one removal plus one addition, which is honest but needs human judgment to interpret). It also works on lists you paste, not on live databases, so it cannot catch drift you have not noticed. For production systems, pair manual diffs with automated schema tests that fail the pipeline when unexpected changes appear.
Who it is for
This tool is for data managers versioning exports, researchers receiving updated datasets from collaborators, and analysts debugging a pipeline that broke after a “small” upstream change. It is a review aid for schema changes, not a migration tool: the decisions it surfaces still need a human.
Going further
Version your schemas like code: give each export a version number, keep a changelog entry per version (“v2: added email, removed city, added country”), and never silently overwrite v1 with v2 under the same filename. Downstream users deserve to know which version they hold, and a changelog turns a diff from a one-time discovery into a permanent record. When a field must be removed, deprecate first — keep it for one version with a warning — so consumers can migrate instead of breaking overnight. Schema stability is a form of respect for everyone downstream, and diffs are how you prove you practised it. Treat renames as breaking changes even when the data is identical: a column renamed from city to town breaks every query, dashboard, and script that referenced city, regardless of whether the values changed. Announce renames in advance, keep the old name as an alias for one version where possible, and update the data dictionary the same day the schema changes — a dictionary that lags the schema misleads everyone who consults it. The diff tells you what changed; the communication plan decides whether anyone survives the change. Automate the diff where you can: a script that compares the new export’s header row against the recorded schema and fails loudly on unexpected changes catches drift at arrival, before any analysis runs on it. Manual diffs with this tool remain valuable for review and for understanding a change, but automation is what prevents a 2 a.m. pipeline failure from becoming a week of wrong results. Pair the two — automated guard, human-reviewed diff — and schema changes become routine instead of emergencies.
Related tools
Versión en español · Data Provenance Log Tracker · All free online tools.
Embed this tool on your website — free
Copy the code below to add this working tool to your own page. A small credit link stays with it — that’s all we ask.

Pingback: SQL Query Visual Flowcharts — Free Basic SELECT Parser