DEV Community: BuildLab

6 Common JSON Errors That Break APIs (And How to Fix Them)

BuildLab — Mon, 12 Oct 2026 06:18:11 +0000

JSON is used everywhere in web development, especially when working with APIs, configuration files, and data exchange.

But even a small syntax mistake can cause parsing to fail. Sometimes the problem is obvious; other times, it is buried inside a large, nested response.

Here are six common JSON errors, why they happen, and how to fix them.

1. Trailing commas

A trailing comma is easy to miss when writing an object or array.

Invalid JSON

{
  "name": "Alice",
  "role": "developer",
}

The comma after "developer" makes this invalid JSON.

Correct JSON

{
  "name": "Alice",
  "role": "developer"
}

JavaScript allows trailing commas in many situations, but standard JSON does not.

2. Using single quotes

JSON requires double quotes around strings and object keys.

Invalid JSON

{
  'name': 'Alice'
}

Correct JSON

{
  "name": "Alice"
}

This often happens when copying a JavaScript object and assuming it is valid JSON.

Remember: a JavaScript object and a JSON document are not the same thing.

3. Forgetting quotation marks around keys

Object keys must be double-quoted strings.

Invalid JSON

{
  name: "Alice",
  age: 25
}

Correct JSON

{
  "name": "Alice",
  "age": 25
}

When an API rejects a payload that looks correct at first glance, check whether every key is enclosed in double quotes.

4. Using unsupported values

JavaScript supports values such as undefined, NaN, and Infinity, but JSON does not.

Invalid JSON

{
  "username": undefined,
  "score": NaN
}

A valid alternative might be:

{
  "username": null,
  "score": 0
}

Choose replacement values according to what the data actually means. null and 0 are not interchangeable.

JSON also doesn't support comments.

5. Incorrectly escaping quotation marks

Strings containing quotation marks need proper escaping.

Invalid JSON

{
  "message": "She said "hello""
}

The parser encounters a quotation mark before hello and treats it as the end of the string.

Correct JSON

{
  "message": "She said \"hello\""
}

The same principle applies to other special characters. For example, use \n to represent a line break inside a JSON string.

6. Missing commas or mismatched brackets

This becomes particularly frustrating with deeply nested objects.

Invalid JSON

{
  "user": {
    "name": "Alice"
    "role": "admin"
  }
}

There is no comma between the two properties.

Correct JSON

{
  "user": {
    "name": "Alice",
    "role": "admin"
  }
}

When debugging a large JSON document, inspect the area around the reported error. The actual mistake may occur earlier than the position shown by the parser.

How to validate JSON in JavaScript

You can use the built-in JSON.parse() method to check whether a string contains valid JSON.

const rawJson = `{
  "user": {
    "name": "Alice",
    "role": "developer"
  }
}`;

try {
  const data = JSON.parse(rawJson);
  console.log("Valid JSON:", data);
} catch (error) {
  console.error("Invalid JSON:", error.message);
}

If the input is valid, JSON.parse() returns the corresponding JavaScript value. Otherwise, it throws a syntax error.

The exact error message depends on the JavaScript runtime, so avoid relying on a particular message when writing error-handling code.

My JSON debugging workflow

When I need to investigate malformed JSON, this is the process I recommend:

Validate the original input.
Inspect the reported error and nearby characters.
Check quotation marks, commas, braces, brackets, and escape sequences.
Fix the syntax and validate it again.
Format the valid JSON to make nested data easier to inspect.

Automatic repair tools can save time, but they should be used carefully. Producing valid JSON is not enough if a repair silently changes the meaning of the original data.

A tool for working with JSON

I built Instant JSON, a browser-based toolkit for formatting, validating, minifying, repairing, sorting, and comparing JSON.

The goal is to make everyday JSON tasks easier to handle in one place, with processing performed directly in the browser rather than uploading JSON payloads to a server.

I'm continuing to improve it and would welcome constructive feedback from developers who work with JSON regularly.

What's the most common JSON error you encounter when debugging APIs, and what is your go-to way to find it?

I Built a Fence Calculator That Actually Plans the Layout

BuildLab — Sun, 04 Oct 2026 17:01:08 +0000

I built a fence calculator that does more than multiply fence length by a material quantity.

👉 Try it: https://www.fencecalculatorhub.com/

While working on this project, I realized that fence planning is actually a small optimization problem disguised as a simple calculator.

If someone says:

"I need 100 ft of fence."

that's not enough information to produce a useful material list.

You still have to figure out things like:

Where the posts should go
How to handle corners
How to handle gates
How many bays are required
How the spacing should be distributed
How many panels, pickets, or rails are needed
How much concrete is required
What the estimated material cost will be

So instead of building another calculator that returns one number, I wanted to build a complete planning workflow.

What I built

Fence Calculator Hub lets you enter the project requirements and work through the fence planning process.

The calculator can handle things such as:

Fence length
Fence type
Post spacing
Corners and structural post roles
Gates
Material quantities
Concrete requirements
Material takeoffs
Planning-level cost estimates
Different layout strategies

One of the interesting parts was making the layout deterministic.

Rather than simply dividing the total fence length by a maximum spacing and rounding the result, the system has to account for the structure of the fence and distribute the bays appropriately.

For example, a 100 ft fence shouldn't just be treated as:

100 / spacing

The actual layout needs to consider where the structural posts belong and how the remaining distance is distributed between them.

The interesting engineering problem

The part I found most interesting was separating the calculation engine from the UI.

The UI is responsible for collecting inputs and presenting the result.

The calculation layer is responsible for things like:

Determining the required structural posts
Establishing the available fence runs
Calculating the number of bays
Distributing spacing
Calculating material quantities
Producing the final takeoff

This makes the calculations easier to test independently from the interface.

It also means that changing the UI doesn't require rewriting the underlying construction logic.

Why build something this specific?

There are thousands of generic calculators on the web.

I wanted to experiment with building a tool around a very specific real-world workflow instead.

The idea is that a useful calculator shouldn't just answer:

"What's the answer?"

It should ideally help answer:

"What should I actually do?"

That's the direction I'm exploring with Fence Calculator Hub.

What I'm still figuring out

This is the first version, and there is still plenty I'd like to improve.

Some of the areas I'm exploring are:

More fence materials and configurations
Better handling of unusual layouts
More detailed material takeoffs
Additional construction calculators
Better visualization
More regional pricing options
More real-world edge cases

I'd especially like feedback from developers who have built calculators, planning tools, estimation software, or other domain-specific web applications.

What would you change about the way this kind of calculator should work?

And if you've built a domain-specific calculator yourself, I'd be interested in hearing what problems you ran into.

I built a fast, private JSON toolkit that runs entirely in your browser

BuildLab — Sun, 04 Oct 2026 16:55:14 +0000

I built a browser-based JSON toolkit because I wanted something simple: paste JSON, work with it, and not have to send the data to a server.

The project is called Instant JSON Formatter.

https://instantjsonformatter.com/

The main idea is privacy + speed. The JSON processing happens directly in the browser rather than sending the JSON to an API.

While building it, I realized that formatting valid JSON is actually the easy part.

The difficult part is everything around it.

I spent a surprising amount of time testing things like:

Missing commas and brackets
Deeply nested objects
Nested arrays
Mixed objects and arrays
Large JSON payloads
Malformed strings
Unexpected primitive values
JSON that is almost valid but isn't
Copying values and JSON paths from nested structures
Comparing two JSON documents

I also worked on auto-fix behavior.

This was probably the most frustrating part.

It is easy to make an "auto-fix" button that changes something and produces valid JSON. It is much harder to make sure the fix doesn't accidentally change what the user actually meant.

So I've been deliberately throwing broken and weird JSON at the tools and testing how they behave.

The current toolkit includes:

JSON Formatter
JSON Validator
JSON Minifier
JSON Viewer / Tree Explorer
JSON Diff
JSON conversion tools

I'm still improving it, so I'd genuinely like feedback from developers who work with JSON regularly.

What is something that annoys you about existing JSON tools?

And if you have a particularly nasty JSON example that you think would break a formatter, feel free to throw it at me. I'm looking for difficult test cases.

I'd especially appreciate criticism about bugs, edge cases, performance, or UX rather than just "looks good."