JSON Validator

Three different things people mean by "valid"

Most of the time a validator gets reached for after something has already broken, and it helps to know which of three questions you are actually asking.

Syntax. Will any parser accept this text? That is what this tool answers, against the grammar in RFC 8259. It is a yes or no with a character position.

Structure. Does this payload have the fields my code expects, of the types it expects? That is JSON Schema, currently at draft 2020-12, and it is a separate step.

Meaning. Is "quantity": 0 a real order or a bug upstream? No tool answers that. Only your own business rules do.

Confusing the first with the second is what puts bad data into a database. Syntax validation passing tells you the text is well formed. It tells you nothing about whether the content makes sense.

A worked example

Here is an order webhook that passes syntax validation cleanly:

{
  "order_id": "ORD-4471",
  "customer": { "name": "Sam Doe", "email": null },
  "items": [],
  "total": "129.99",
  "currency": "gbp",
  "placed_at": "12/08/2026"
}

Every one of those lines is valid JSON, and every one of them is a problem:

• email is null, not missing. Code that checks if (customer.email) handles it; code that checks if ("email" in customer) does not.
• items is an empty array. An order with no line items should almost certainly never have been accepted.
• total is a string. "129.99" + 10 gives "129.9910" in JavaScript.
• currency is lowercase where ISO 4217 codes are uppercase, so a lookup against GBP misses.
• placed_at is ambiguous. 12/08/2026 is 12 August in Britain and 8 December in the United States, and nothing in the payload says which. RFC 3339 date-time, 2026-08-12T14:30:00Z, is the only form that cannot be misread.

A JSON Schema catches the first four before your code ever sees them:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["order_id", "customer", "items", "total", "currency"],
  "properties": {
    "customer": {
      "type": "object",
      "required": ["email"],
      "properties": { "email": { "type": "string", "format": "email" } }
    },
    "items": { "type": "array", "minItems": 1 },
    "total": { "type": "number", "exclusiveMinimum": 0 },
    "currency": { "type": "string", "pattern": "^[A-Z]{3}$" },
    "placed_at": { "type": "string", "format": "date-time" }
  }
}

Run it with Ajv in Node, jsonschema in Python, or the schema validator built into most API gateways. It is perhaps twenty minutes of work and it converts a class of silent corruption into a loud, early failure.

Where to put validation

The edge is where the value is. A webhook receiver that returns a 400 with a clear message forces the sender to fix their payload; one that accepts anything and half-processes it makes the problem yours.

Mistakes worth knowing about

Treating a pass as an all-clear. Covered above, and it is the reason most people arrive here twice.

Validating a string that contains JSON. If a field's value is "{\"id\":7}", the outer document is valid and the inner object is invisible to every check you run. Parse it a second time, or fix the sender.

Assuming key order. The RFC is explicit that parsers differ on whether they expose member ordering at all. Never write logic that depends on it.

Duplicate keys. Legal JSON, unpredictable behaviour, no warning anywhere. Most parsers keep the last occurrence and drop the first.

Silent type coercion. Ajv can coerce "5" to 5 when you ask it to, which is convenient in a form handler and dangerous on a financial field. Read the coercion rules before switching it on.

Frequently Asked Questions

Does this tool validate against a JSON Schema?

No — it checks syntax only, which is the fast question and the one you usually need answered first. For schema validation, write the schema against the 2020-12 specification and run it with a library in your own stack, where it can run on every request rather than on the one payload you happened to paste.

Is my data sent to a server?

No. Validation happens in your browser, so a payload containing a customer email or a bearer token stays on your machine. That is worth checking on any online validator before you paste production data into it.

Why does the error position look wrong?

The position is the first character the parser could not accept, which is often just after the real mistake. A missing comma on line 4 is reported at the start of line 5, because line 4 was fine until something followed it that should not have. Format the document with the JSON Formatter and read the error against the formatted version.

My JSON is valid but my automation still fails. Why?

Because valid is a low bar. Nine times out of ten the payload is fine and the mapping is wrong — a field nested one level deeper than expected, an array where a single object was assumed, or a value that is null rather than absent. The Make.com Error Handling tutorial covers how to catch that in the workflow rather than after the write.

Should I validate JSON I generate myself?

In tests, yes. Anything built by string concatenation rather than a serialiser will eventually meet a value containing a quotation mark or a newline and produce a broken document. Use your language's JSON serialiser and the problem does not arise.

Next steps

If you are validating because an integration keeps breaking, the n8n Webhook Tutorial walks through building a receiver that rejects bad payloads properly, and the API Request Tester lets you fire a request and inspect exactly what comes back.

If you would rather someone else built the integration so this stops happening, I take on this work as a freelancer — start a project on Fiverr or hire me on Upwork.