Why manual json schema validator fails on real files

An upstream service changes a field from a string to a number. Nothing crashes; the value is silently coerced; two weeks later a report is wrong and nobody knows which release did it.

You see this most often in API contracts, webhook consumers, test fixtures. Reading a payload by eye does not scale past a handful of fields, and type errors are invisible until arithmetic happens.

What actually goes wrong

Manual handling fails in a specific way: it does not produce obviously broken output, it produces output that is almost right. Reading a payload by eye does not scale past a handful of fields, and type errors are invisible until arithmetic happens. The mistake survives review because nothing looks wrong until an importer rejects the file or a report is quietly incorrect.

A cheaper habit

Check the file before it leaves your machine. That is the entire purpose of JSON Schema Validator — it reads the data you paste, applies the same rules an importer would, and shows the row that will break, rather than a summary of how many rows broke.

Every violation reports its full path, so a nested array element is identified precisely instead of being described as "somewhere in the payload".

For the full picture — imports, feeds, variants, identifiers — see the pillar guide: Shopify product data management.

Try it on your own file

Open JSON Schema Validator and paste a sample. It is free, it does not store anything, and you do not need an account. If the file is sensitive, save the page locally and run it offline.

Questions people ask

Which schema features are supported?

Type, required, properties, items and enum — the subset that catches real breakage.

Does it report every violation?

Yes, it walks the whole document and lists each path, not just the first.