JSON Formatting and Validation: A Practical Developer Guide

A json formatter online is one of the most-used tools in any developer's daily workflow. JSON (JavaScript Object Notation) is the format of REST API responses, configuration files, database query results, and inter-service communication. Despite its apparent simplicity, JSON errors are surprisingly common, and the error messages they produce are notoriously unhelpful. 'Unexpected token at position 2847' tells you where the parser gave up, not what caused the problem. This guide covers the most common errors, how to debug API responses step by step, JSON Schema validation with real examples, and how different types of formatters compare.

JSON syntax rules: the complete list

JSON has six data types (string, number, boolean, null, object, array) and a strict syntax. These are every rule you need to know:

• •Strings must be in double quotes. Single quotes are not valid JSON.
• •Object keys must be strings in double quotes. Unquoted keys are not valid.
• •Arrays use square brackets, objects use curly braces.
• •No trailing commas. A comma after the last item in an array or object is a syntax error.
• •No comments. Neither // nor /* */ are valid in JSON.
• •Numbers must not have leading zeros (01 is invalid; 1 is correct).
• •Booleans are lowercase: true and false, not True or False.
• •Null is lowercase: null, not Null or NULL.
• •Strings cannot contain literal newlines: use the escape sequence \n instead.
• •Unicode escape sequences in strings must be exactly four hex digits: \u0041 is valid, \u41 is not.

The most common JSON errors and how to fix them

Trailing comma

// INVALID: trailing comma after last item
{
  "name": "Alice",
  "age": 30,
}

// VALID
{
  "name": "Alice",
  "age": 30
}

This is the most common mistake for developers coming from JavaScript, where trailing commas are allowed. Copy-pasting from JS code into a JSON file reproduces this error constantly.

Single quotes

// INVALID: single quotes
{
  'name': 'Alice'
}

// VALID
{
  "name": "Alice"
}

Unquoted keys

// INVALID: unquoted key (valid in JavaScript, not in JSON)
{
  name: "Alice"
}

// VALID
{
  "name": "Alice"
}

Comments

// INVALID: JSON does not support comments
{
  // user details
  "name": "Alice",
  "age": 30 /* years old */
}

// VALID: remove all comments
{
  "name": "Alice",
  "age": 30
}

Numbers stored as strings

// These are different types:
{ "count": "42" }   // string — cannot do arithmetic
{ "count": 42 }    // number — arithmetic works

// Common cause: reading from a CSV or form input
// without parsing the value

Why a json formatter online makes debugging faster

Minified JSON (everything on one line with no whitespace) is efficient to transmit but unreadable when you need to find an error. When an API returns 5 KB of minified JSON and your parser throws at position 2847, you need to count 2,847 characters along a single line to find the problem. A formatter that pretty-prints with indentation makes the structure immediately readable and locates errors at a specific line number rather than a character offset.

A good JSON formatter online does more than add whitespace. It validates syntax while formatting, highlights the exact line containing an error, collapses and expands nested objects in a tree view, and shows the depth of nesting visually. AlteredIdea's JSON Formatter provides all of these in your browser: your data never leaves your device, which matters when debugging API responses containing sensitive fields.

Debugging API responses: step-by-step walkthrough

This is the workflow for diagnosing a JSON error in an API response, from the raw error to the identified cause.

1. 1.Capture the raw response. In your browser's DevTools (F12, Network tab), find the failing request, click it, and look at the Response tab. Copy the full response body.
2. 2.Paste it into a JSON formatter. If the response is valid JSON with unexpected data, formatting will reveal the structure. If the formatter reports a syntax error, you have found the first problem: the API is returning malformed JSON.
3. 3.Read the error location. A good formatter reports the line and character where the error was found. Navigate to that line in the formatted view.
4. 4.Look at the characters immediately before the error location, not at the error location itself. JSON parsers report where they gave up, which is typically after the actual mistake. A missing comma on line 14 causes the error to be reported on line 15.
5. 5.Check for the common culprits at that location: missing or extra comma, missing quote, unmatched bracket or brace.
6. 6.If the JSON is valid but the data is wrong, use the tree view to navigate the structure. Expand nested objects to find the field you expect. Compare the field names case-sensitively: userId and userid are different keys.
7. 7.If a required field is missing, the API contract (the expected schema) and the actual response have diverged. This is a backend bug, not a JSON bug. Document the expected versus actual structure to report it clearly.
8. 8.For intermittent errors, capture multiple responses and compare them. A JSON diff tool shows exactly which fields differ between two valid responses.

JSON Schema: validating structure, not just syntax

Valid JSON syntax and valid JSON data are two different things. A response that parses without errors but has the wrong field names, wrong types, or missing required fields will still break downstream code. JSON Schema is a standard for defining the expected structure of a JSON document and validating any JSON against it.

Here is what JSON Schema looks like in practice.

Basic schema: required fields and types

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "name", "email"],
  "properties": {
    "id": {
      "type": "integer"
    },
    "name": {
      "type": "string",
      "minLength": 1
    },
    "email": {
      "type": "string",
      "format": "email"
    }
  }
}

This schema says: the JSON must be an object with three required fields. id must be an integer. name must be a non-empty string. email must be a string in email format. Any JSON missing one of these fields, or with id as a string rather than an integer, will fail validation.

Schema with nested objects and arrays

{
  "type": "object",
  "required": ["user", "orders"],
  "properties": {
    "user": {
      "type": "object",
      "required": ["id", "name"],
      "properties": {
        "id": { "type": "integer" },
        "name": { "type": "string" }
      }
    },
    "orders": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["orderId", "total"],
        "properties": {
          "orderId": { "type": "string" },
          "total": { "type": "number", "minimum": 0 }
        }
      }
    }
  }
}

This schema validates a user object with a nested orders array. Each order must have an orderId string and a non-negative total number. This kind of schema is directly generated from an API contract or OpenAPI specification and used to validate every response in integration tests.

Schema with enum and pattern constraints

{
  "type": "object",
  "properties": {
    "status": {
      "type": "string",
      "enum": ["pending", "active", "cancelled"]
    },
    "postcode": {
      "type": "string",
      "pattern": "^[A-Z]{1,2}[0-9][0-9A-Z]? [0-9][A-Z]{2}$"
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    }
  }
}

Enum constraints catch statuses that are not in the allowed set. Pattern constraints validate format strings like postcodes, phone numbers, or reference numbers against a regex. Format constraints (date-time, email, uri) validate string formats defined by the JSON Schema specification.

Comparing JSON formatter tools

JSON formatting is available in several different forms. Each has a different home context and set of trade-offs.

For most day-to-day debugging, a browser-based formatter is the fastest option: no context switch from the browser where you saw the error, no install, and immediate access from any computer. AlteredIdea's JSON Formatter runs entirely in your browser without sending data to any server, which covers the privacy advantage of local tools while keeping the convenience of online access.

Practical tips for working with JSON

• •Always format API responses during development. Reading minified JSON is slow and error-prone. Formatting takes one paste and one click.
• •Treat the error location as a clue, not the cause. JSON parsers report where they gave up. The actual mistake is almost always in the line or two before the reported error.
• •Use tree view for deeply nested objects. Collapsing top-level keys and expanding only the branch you are investigating is faster than reading a long flat list.
• •Compare two responses with a diff tool when debugging intermittent issues. A diff shows exactly which fields changed between a working and a broken response.
• •Use JSON path expressions ($.user.address.city) to extract specific values in test assertions without coupling to the full document structure.
• •When converting from JavaScript to JSON, remove all comments, change single quotes to double quotes, add quotes to unquoted keys, and remove trailing commas.
• •Validate against a schema in integration tests, not just in development. Schema validation in CI catches API contract changes before they reach production.

Converting between JSON and other formats

JSON is the standard data format for APIs, but data frequently needs to move between JSON and other formats for different parts of a workflow.

• •JSON to CSV: useful for loading API data into spreadsheets or importing into databases. Arrays of flat objects convert cleanly. Nested objects must be flattened first (user.name becomes user_name as a column header). Arrays within objects cannot be represented in CSV without restructuring.
• •JSON to YAML: used for configuration files (Kubernetes, Docker Compose, GitHub Actions). The conversion is mostly direct: YAML is a superset of JSON. Watch for YAML's reserved values: yes, no, on, off are interpreted as booleans in YAML, which can cause surprises when a JSON string '"no"' becomes a YAML boolean.
• •JSON to XML: required for legacy system integration, SOAP APIs, and some enterprise platforms. JSON has no equivalent for XML attributes, and XML requires a root element that JSON does not. The conversion is tool-dependent and should be tested carefully.

Frequently asked questions

1. 1.What is the difference between JSON formatting and JSON validation? Formatting adds whitespace and indentation for readability but does not check correctness. Validation checks that the JSON is syntactically correct (parseable) and optionally that it matches an expected schema. A formatter can also validate: a formatter that reports errors is doing both.
2. 2.Why does my JSON look valid but still cause errors in my code? Syntax validity and semantic validity are different. The JSON may be syntactically correct but have the wrong field names (userId vs user_id), wrong types (string where a number is expected), or missing required fields. Use JSON Schema validation to catch these differences.
3. 3.Can I format JSON with sensitive data safely? With a browser-based formatter that runs locally, yes. AlteredIdea's formatter never sends your data to a server. With a server-based formatter, your data travels over the network to a third-party server, which is a risk for sensitive API responses or configuration files containing credentials.
4. 4.What is the maximum size of JSON I can format? There is no size limit enforced by AlteredIdea's formatter. The practical limit is your browser's available memory. Files up to tens of megabytes format without issue on most computers.
5. 5.Is JSONC (JSON with comments) valid JSON? No. JSONC is a dialect used by some configuration files (VS Code's settings.json, TypeScript's tsconfig.json). It adds comment support but is not standard JSON. JSONC files will fail in a standard JSON parser. Strip comments before parsing them as JSON.