5 JSON Mistakes That Break Your API Calls

You've written the fetch call. The endpoint is correct. The headers look right. But the API returns a 400 Bad Request — or worse, a cryptic parsing error with no useful information. Nine times out of ten, the problem is in your JSON. Here are the five mistakes that trip up developers constantly, how to spot them, and how to fix them in seconds.

1. The Trailing Comma

This is the single most common JSON syntax error. JavaScript allows trailing commas in objects and arrays. JSON does not. Your editor won't flag it. Your linter might miss it. But the API's JSON parser will reject it immediately.

// This breaks
{
  "name": "OneKit",
  "version": "1.0",
  "tools": 20,  ← trailing comma
}

// This works
{
  "name": "OneKit",
  "version": "1.0",
  "tools": 20
}

The fix is simple but the problem is hard to see when you're scanning a 200-line payload. A JSON formatter catches it instantly by refusing to parse the invalid structure and pointing you to the exact line.

2. Single Quotes Instead of Double Quotes

JavaScript accepts both single and double quotes for strings. JSON is strict — only double quotes are valid. This catches Python developers especially, since Python's json.dumps() outputs double quotes but developers often write test payloads by hand using single quotes.

// This breaks
{'name': 'OneKit'}

// This works
{"name": "OneKit"}

This error is particularly common when copying data from Python dictionaries, YAML files, or console output and pasting it directly into an API testing tool.

3. Unquoted Keys

In JavaScript, object keys don't need quotes if they're valid identifiers. In JSON, every key must be a double-quoted string. No exceptions.

// This breaks
{name: "OneKit", tools: 20}

// This works
{"name": "OneKit", "tools": 20}

This one shows up most often when developers hand-write JSON payloads or convert JavaScript object literals to JSON without running them through a serializer. If you're writing JSON manually, always quote your keys.

4. Wrong Value Types

An API expects "count": 20 (a number) but you send "count": "20" (a string). The JSON is valid either way, so a syntax validator won't catch it. But the API's schema validation will reject it, and the error message often doesn't tell you which field has the wrong type.

The most common type mismatches are numbers sent as strings (often from form inputs that capture everything as text), booleans sent as strings ("true" vs true), and null vs the string "null". A JSON formatter with syntax highlighting makes these visible — strings show up in a different color than numbers and booleans, so type mismatches become obvious at a glance.

5. Missing or Mismatched Brackets

Deeply nested JSON structures make it easy to lose track of opening and closing brackets. A missing ] or } three levels deep produces an error that points to the end of the file — not to the line where the bracket was supposed to be. This sends developers on a line-by-line hunt that wastes time.

// Where's the missing bracket?
{
  "users": [
    {
      "name": "Alice",
      "roles": ["admin", "editor"
    },
    {
      "name": "Bob",
      "roles": ["viewer"]
    }
  ]
}

A formatter catches this immediately because it can't parse the structure past the point of failure. Paste it in, see exactly where it breaks, fix the bracket, and move on. What would take five minutes of manual scanning takes two seconds.

The Fix That Covers All Five

Every one of these mistakes is caught by running your JSON through a formatter before sending it. It's the same logic as running a spell check before sending an email — it takes seconds and catches the errors your eyes skip.

And if you're debugging response data that includes patterns you need to extract — IDs, timestamps, URLs — pairing a formatter with a regex tester gives you a complete debugging workflow without leaving your browser.

The fastest way to debug a 400 error: paste the payload into a formatter before you start reading the logs. Half the time, the problem was in the JSON all along.