Validate JSON syntax before it reaches production

Strict JSON uses double-quoted strings, commas between members and elements, and a defined set of value forms: object, array, string, number, boolean, and null. JavaScript conveniences such as comments, undefined, NaN, Infinity, functions, and trailing commas are not part of the JSON grammar. A validator should expose those differences instead of accepting a broader language silently.

A valid result means the browser parsed the complete text and the value stayed within Tool Swim's size and traversal limits. It does not mean a user record includes every required field, a date string follows an expected format, or an identifier exists in another system. Those are data-contract questions for JSON Schema or application validation.

When the JavaScript runtime exposes a character position, Tool Swim maps it to a line and column for the current input. The reported location is usually where parsing became impossible, which can be just after the true mistake. A missing comma on one line may therefore surface at the next member name.

Start at the reported location, then inspect the preceding delimiter, quote, bracket, or brace. Preserve the original document while correcting one issue at a time. That method avoids a global replace turning valid string content into a second error.

Browser validation is useful for an immediate check, but production confidence comes from enforcing the same rule in tests, request handlers, configuration loaders, and build pipelines. Save a malformed example beside the valid fixture so future changes prove the failure path still works.

For payloads containing secrets or personal data, avoid copying the entire error context into logs. Record a stable error class and safe location metadata, then keep the original content inside the authorized debugging boundary. This tool sends neither the document nor free-form parser messages as telemetry.