How to validate JSON without uploading sensitive data

JSON validation answers a narrow but important question: does this text conform to the JSON grammar accepted by the parser? It can identify malformed strings, missing separators and invalid structural characters. It cannot prove that field names are correct, values meet an API contract or the receiving system will authorize the request.

That distinction matters during troubleshooting. A payload can be valid JSON and still violate a JSON Schema, contain the wrong identifier, use an unexpected date format or fail a business rule. Record syntax validation as one observation in the investigation, not as a blanket statement that the payload is correct.

Do not paste an unedited production request merely because a tool processes locally. Remove access tokens, cookies, email addresses, customer text, internal hostnames and identifiers that are unnecessary to reproduce the parsing problem. Replace them with obviously synthetic values while preserving quotation marks, commas, nesting and the data type of each value.

If removing a field makes the error disappear, add fields back one at a time using synthetic data. This produces a minimal reproducer that is safer to share and usually makes the actual syntax fault easier to see.

• Keep structural characters and value types intact.
• Replace secrets rather than masking only their first or last characters.
• Avoid putting the payload in a URL, screenshot or shared browser history.
• Retain the smallest example that still triggers the error.

{
  "requestId": "example-123",
  "enabled": true,
  "roles": ["reader"]
}

A parser often reports where it became unable to continue, which may be just after the real mistake. For example, a missing comma can cause the next property name to be reported as unexpected. Inspect the reported line and column, then review the preceding token and the enclosing object or array.

After fixing the first error, validate again. Parsers frequently stop at the earliest fatal issue, so a second independent problem may only become visible after the first is corrected. Once syntax passes, move to contract validation or a controlled request in the appropriate non-production environment.

• Check for missing commas between members and array items.
• Use double quotes for JSON property names and string values.
• Remove trailing commas unless the target explicitly accepts a non-JSON extension.
• Check that braces, brackets and quoted strings are properly closed.

A strong troubleshooting note states the tool and version, the time of the check, the safe sample used, the exact parser outcome and the next validation step. Avoid copying the original sensitive payload into the ticket. If a hash is used to identify an artefact, explain what was hashed and do not imply that a hash proves the content was safe or authentic.

The final note should distinguish observed fact from interpretation: for example, ‘the synthetic payload parsed as RFC 8259 JSON’ is an observation; ‘the production request should now succeed’ is an untested prediction.