How to Format and Validate JSON Online

Why JSON Formatting Matters

JSON (JavaScript Object Notation) is a lightweight data-interchange format defined at json.org and standardised as ECMA-404 and RFC 8259. It is the dominant format for web APIs, configuration files, and data storage.

The problem is that compact, minified JSON — all on one line without indentation — is nearly unreadable by humans. When debugging an API response or editing a config file, readable JSON is essential. Formatting adds whitespace and indentation to reveal the structure without changing any data.

JSON Syntax Rules

JSON has strict and simple syntax rules. Understanding them prevents the most common errors:

• Strings must use double quotes — "name" is valid; 'name' is not.
• Keys must be strings — {"name": "Alice"} is valid; {name: "Alice"} is not.
• No trailing commas — the last item in an object or array must not have a trailing comma.
• No comments — JSON does not support single-line (//) or multi-line (/* */) comments.
• Supported types: string, number, boolean (true/false), null, array ([]), object ({}).
• Numbers: no leading zeros; 0.5 is valid; 05 is not.

These rules are more restrictive than JavaScript object literal syntax, which is a common source of confusion. Valid JavaScript objects are not always valid JSON.

Common JSON Errors

Trailing Comma

This is the most frequent JSON error, particularly when copy-pasting from JavaScript code:

// Invalid JSON
{
  "name": "Alice",
  "age": 30,  ← trailing comma
}

// Valid JSON
{
  "name": "Alice",
  "age": 30
}

Single Quotes

// Invalid JSON
{'name': 'Alice'}

// Valid JSON
{"name": "Alice"}

Unquoted Keys

// Invalid JSON
{name: "Alice"}

// Valid JSON
{"name": "Alice"}

Comments

JSON has no comment syntax. Attempting to add // or /* */ comments produces a parse error. If you need comments in configuration files, consider JSONC (JSON with Comments) or YAML instead — but strip comments before parsing as standard JSON.

Pretty-Printing JSON

Pretty-printing adds indentation (usually 2 or 4 spaces per level) and line breaks to make the structure visible. It is purely cosmetic — the data is identical before and after formatting.

Minified input:

{"user":{"name":"Alice","age":30,"tags":["admin","user"]}}

Pretty-printed output:

{
  "user": {
    "name": "Alice",
    "age": 30,
    "tags": [
      "admin",
      "user"
    ]
  }
}

ToolMasta's JSON Formatter pretty-prints instantly as you type. Indentation level (2 or 4 spaces) is configurable.

JSON Minification

Minification is the inverse of pretty-printing — it removes all non-essential whitespace to produce the smallest valid JSON string. This is used to:

• Reduce API response payload size
• Minimise storage space for JSON documents in databases
• Slightly improve parse time (fewer characters to scan)

The size reduction depends on how much whitespace was in the original. A heavily indented document with 4-space indentation can be reduced by 30–50% in size through minification. A document with 2-space indentation will see less reduction.

Validating JSON

JSON validation confirms that a document is syntactically valid according to the JSON specification. A validator parses the input using a strict parser and reports the exact location of any error.

Most JSON formatters validate automatically before formatting. If validation fails, they report the line and column number of the error so you can fix it immediately. This is far faster than trying to spot a missing quote or extra comma manually in a large document.

JSON Schema Validation

Syntax validation only confirms the document is well-formed JSON. Schema validation goes further: it checks whether the data conforms to an expected structure defined by a JSON Schema document.

A JSON Schema can specify:

• Required fields and their types
• Minimum and maximum values for numbers
• String patterns (regex)
• Array item types and constraints
• Enumerated values

Schema validation is used in API contracts (OpenAPI/Swagger), form validation, and configuration file verification. It catches data errors that syntax validation misses — for example, a field that should be a number but received a string.

When to Format vs. Minify

Scenario	Format (Pretty-Print)	Minify
Reading and debugging	Yes	No
API responses in production	No	Yes
Configuration files checked into version control	Yes (diff-friendly)	No
Stored documents in a database	No	Yes
Developer documentation examples	Yes	No
Log files	No	Yes (one record per line)