Formatting and validating JSON are related tasks, but they answer different questions. Formatting changes whitespace so a payload is easier to read. Syntax validation determines whether the text follows the JSON grammar. Schema or application validation asks whether the parsed value has the fields, types, and rules a particular system expects. A payload can therefore look tidy and still be invalid, or parse successfully and still be unusable by an API.

A reliable workflow keeps those stages separate. Preserve the original input, run a strict parser, use the reported location to fix syntax, format the valid result, and then compare its structure with the contract. This guide explains that process and the mistakes that most often interrupt it.

What valid JSON actually allows

JSON has a deliberately small vocabulary: objects, arrays, strings, numbers, the literals true and false, and null. Object property names and string values use double quotes. Commas separate members or array items, while colons separate property names from values. Whitespace may appear around structural characters without changing the data.

The formal standard, RFC 8259, permits any JSON value at the top level, although objects and arrays remain the most interoperable choices. It does not permit comments, trailing commas, single-quoted strings, NaN, or Infinity. Those constructs may work in a JavaScript file or a tolerant configuration parser, but they are not strict JSON.

Formatting is not the same as repairing

A JSON formatter, sometimes called a pretty printer, normally parses the input and serializes it with consistent indentation and line breaks. Minification performs the reverse presentation change by removing insignificant whitespace. Neither operation should invent a missing quote, delete an extra comma, or guess what a malformed value was meant to be. Silent repairs make it difficult to know whether the data still represents the producer's intent.

When a formatter rejects the input, treat that failure as useful evidence. Keep an untouched copy, note the character or line reported by the parser, and inspect the surrounding structure. After the syntax is fixed, formatting makes nested objects and arrays visible, which is especially helpful when reviewing an API response, webhook, log entry, or configuration document.

Common JSON syntax errors and how to find them

Trailing commas are a frequent failure: {"active": true,} is not valid. So are single quotes, unescaped double quotes inside strings, missing commas between members, and literal line breaks inside quoted text. Property names must be quoted even when they would be valid JavaScript identifiers. Literal names are lowercase, so True, NULL, and undefined fail.

The parser's position often marks where parsing became impossible, not where the mistake began. An “unexpected end” error may mean that an earlier object, array, or string was never closed. An error beside a property name may be caused by a missing comma on the previous line. Work outward from the reported point and match opening braces, brackets, quotes, and separators.

A practical validation workflow

Start with the exact bytes received. If data came from HTTP, check the status code and Content-Type before assuming the body is JSON; login pages and proxy errors are often HTML. Next, paste a safe, non-secret sample into a strict JSON validator or run the platform parser. In JavaScript, JSON.parse() returns the represented value and throws a SyntaxError for invalid JSON.

Fix one error at a time, because the first structural problem can produce several misleading symptoms. Once parsing succeeds, format with two or four spaces, inspect the nesting, and compare the result with the API documentation or schema. Finally, add the corrected payload as a test fixture so the same edge case cannot return unnoticed.

Syntax validation does not validate meaning

The document {"email": 42} is valid JSON, but an account API probably expects the email to be a string. A timestamp can be a valid string while using the wrong format. A required property may be absent, an enum may contain an unknown value, or an array may exceed an accepted limit. These are contract errors, not JSON grammar errors.

Use JSON Schema, OpenAPI validation, or application rules for this second layer. Define required and optional properties, allowed types, formats, ranges, and whether additional properties are accepted. Error messages should distinguish malformed JSON from a well-formed payload that violates the contract, because the person integrating the API needs a different remedy for each.

Numbers, Unicode, and duplicate keys need care

Valid syntax can still hide interoperability problems. JSON defines numbers without prescribing one universal runtime representation. Large integer identifiers may lose precision in environments based on IEEE 754 binary64 numbers, so opaque IDs are often safer as strings. Exact monetary values also need an agreed representation rather than an assumption that every parser treats decimals identically.

JSON exchanged between open systems should use UTF-8. Escaped and unescaped Unicode can represent the same characters, which matters if code compares raw bytes or signs a document. Duplicate object names are another trap: parsers may keep the first value, keep the last, or report an error. Producers should emit unique property names, and security-sensitive consumers should reject ambiguous input.

How to format JSON without exposing secrets

Before using any external formatter, inspect the payload for access tokens, passwords, personal data, private keys, session cookies, or internal URLs. Prefer a tool that runs locally in the browser and does not upload input. For production incidents, create a reduced sample and replace sensitive values while preserving the structure that reproduces the problem.

Do not paste a live credential merely because the surrounding document is difficult to read. Redaction should happen before sharing or logging, and it should cover nested fields as well as obvious top-level names. When a value must retain a particular length or character pattern for testing, substitute a synthetic equivalent instead of masking only part of the original secret.

Format for people, validate for systems

The shortest useful rule is simple: parse first, format second, validate the contract third. Pretty indentation helps a person understand a payload, but only a strict parser proves that it is JSON, and only a schema or application check proves that the data belongs in a particular workflow.

Use the JSON formatter and validator to make syntax errors visible, then examine types, required fields, numeric precision, encoding, and security separately. That layered approach turns an opaque parser message into a repeatable debugging process and keeps “valid JSON” from being mistaken for “correct data.”