DEV Community: 99Tools

Think JSON.stringify() is simple? Think again. Learn how JSON to String conversion really works, avoid common mistakes, handle edge cases, and write cleaner JavaScript with practical examples you can use today.

99Tools — Thu, 30 Jul 2026 14:36:55 +0000

99Tools

Jul 30

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

#javascript #webdev #tutorial #beginners

10 min read

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

99Tools — Thu, 30 Jul 2026 14:33:57 +0000

A few years back, I spent about twenty minutes debugging why a user's shopping cart kept resetting on page refresh. The code looked completely fine:

localStorage.setItem("cart", cartItems);

Open dev tools, check localStorage, and there it is: "[object Object]". Not the data. Just that string, staring back at me.

That bug — and the dozens of variations of it I've seen since, in code reviews and Stack Overflow threads alike — comes down to one missing step: turning a JavaScript object into an actual JSON string before handing it to something that only understands strings. This guide covers that step in depth: how it works, where you'll use it, and the edge cases that will eventually get you if nobody tells you about them first.

TL;DR

Use JSON.stringify(value) to convert a JS value into a JSON-formatted string.
Use JSON.stringify(value, null, 2) when you want it human-readable.
undefined, functions, and symbols are silently dropped. NaN and Infinity become null.
Circular references and BigInt values throw errors — they don't fail quietly.
JSON.parse(JSON.stringify(x)) is not a safe deep clone. Use structuredClone(x) instead.
JSON.parse(str, reviver) lets you rebuild things like Date objects on the way back in.

If you already know all that, you probably don't need this article — but stick around anyway, there are a couple of gotchas below that surprise even people who've been writing JavaScript for years.

First, Let's Clear Up the Terminology

"JSON" stands for JavaScript Object Notation, and it's a text format — it's already string-shaped by definition. So when developers say "convert JSON to a string," what they almost always mean is:

"I have a JavaScript object (or array, or value), and I need to represent it as JSON-formatted text."

That distinction matters, because it's not the same operation as "converting an object to a string" in the generic sense. Which brings us to a trap a lot of beginners fall into first.

The Wrong Way (and Why It Fails)

If you're new to JavaScript, converting a value "to a string" might reasonably make you reach for String(), .toString(), or a template literal. Try that on an object, though, and here's what happens:

const user = { name: "Maya", age: 29 };

String(user);        // "[object Object]"
`${user}`;            // "[object Object]"
user.toString();      // "[object Object]"

All three quietly return the same useless placeholder. That's because objects don't have meaningful default string representations — [object Object] is just JavaScript telling you "yep, this is an object," which you already knew.

JSON.stringify() is a different operation entirely. Instead of asking "what's the string form of this object," it serializes the object — walking through its structure and producing a text representation of the data itself:

JSON.stringify(user);
// '{"name":"Maya","age":29}'

That's the method you actually want.

The Core Method: `JSON.stringify()`

const user = {
  name: "Maya",
  age: 29,
  isActive: true
};

const jsonString = JSON.stringify(user);

console.log(jsonString);
// '{"name":"Maya","age":29,"isActive":true}'

console.log(typeof jsonString);
// "string"

Your object is now plain text. It looks like the object literal you started with, but functionally it isn't — you can't do jsonString.name anymore, because there's no object there to access. If you need the data back in object form, you'll need JSON.parse(), which we'll get to.

Making Output Readable: The Indentation Argument

Compact JSON is great for sending over a network, but it's rough to read in a console log or a debug file. JSON.stringify() accepts a third argument for that:

JSON.stringify(user, null, 2);
/*
{
  "name": "Maya",
  "age": 29,
  "isActive": true
}
*/

The 2 means "indent with 2 spaces." You could pass 4, or even a string like "\t" for tabs. I default to 2 in almost every debugging session I run — it turns a wall of text into something I can actually scan.

Controlling What Gets Included: The Replacer

The second argument — the one we skipped with null above — is called the replacer, and it's more powerful than most quick tutorials let on.

As a function, it runs against every key/value pair, so you can filter or transform data on the way out:

const account = {
  username: "maya_codes",
  password: "supersecret123",
  email: "maya@example.com"
};

const safeJson = JSON.stringify(account, (key, value) => {
  if (key === "password") return undefined;
  return value;
});

console.log(safeJson);
// '{"username":"maya_codes","email":"maya@example.com"}'

This is genuinely useful for scrubbing sensitive fields — tokens, passwords, internal IDs — before you log an object or send it somewhere it shouldn't end up.

As an array, it works as a simple whitelist instead:

JSON.stringify(account, ["username", "email"]);
// '{"username":"maya_codes","email":"maya@example.com"}'

Same result, less code — but no custom logic, so pick whichever fits your situation.

Custom Serialization With `toJSON()`

Here's a trick that doesn't get nearly enough attention: any object can define its own toJSON() method, and JSON.stringify() will call it automatically instead of serializing the object's raw properties.

class Money {
  constructor(cents) {
    this.cents = cents;
  }

  toJSON() {
    return (this.cents / 100).toFixed(2);
  }
}

const price = new Money(1999);

console.log(JSON.stringify({ price }));
// '{"price":"19.99"}'

This is exactly how Date objects manage to serialize cleanly (more on that below) — Date.prototype.toJSON() is built in. If you're building your own classes and want them to serialize predictably, this is the hook to use instead of fighting with replacer functions everywhere they're used.

Where You'll Actually Use This

Storing Data in `localStorage` or `sessionStorage`

Both storage APIs only accept strings — this is the bug from the intro:

const cartItems = [{ id: 1, qty: 2 }, { id: 2, qty: 1 }];

localStorage.setItem("cart", JSON.stringify(cartItems));

// later:
const cart = JSON.parse(localStorage.getItem("cart"));

Sending Data With `fetch()`

Request bodies are strings too, not live objects:

fetch("/api/orders", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ item: "Keyboard", quantity: 1 })
});

Skip this step, and your server usually receives something it can't parse, no matter what the Content-Type header claims.

Logging and Debugging

Deeply nested objects often get truncated or collapsed in browser and Node consoles. Stringifying first gives you a flat snapshot you can actually read or paste into a bug report:

console.log(JSON.stringify(apiResponse, null, 2));

Comparing or Hashing Objects

JSON.stringify() is also a common (if imperfect) shortcut for comparing two objects by value, since JavaScript's === only checks reference equality:

const a = { x: 1, y: 2 };
const b = { x: 1, y: 2 };

a === b; // false
JSON.stringify(a) === JSON.stringify(b); // true

It's worth knowing this trick exists — just also worth knowing it breaks if the keys are in a different order or the objects contain any of the quirks below. For anything beyond quick scripts or tests, a proper deep-equality check (like lodash.isEqual) is more reliable.

The Gotchas (Learned the Hard Way)

Some Values Just Disappear

JSON.stringify() silently drops undefined values, functions, and Symbol keys — no error, no warning:

const obj = {
  name: "test",
  greet: function () { return "hi"; },
  id: undefined,
  tag: Symbol("x")
};

console.log(JSON.stringify(obj));
// '{"name":"test"}'

If a field you swear you set is missing from an API payload or a stored object, this is worth checking first.

`NaN` and `Infinity` Become `null`

JSON.stringify({ score: NaN, limit: Infinity });
// '{"score":null,"limit":null}'

JSON has no concept of these values, so JSON.stringify() falls back to null instead of throwing.

Circular References Throw

If an object references itself — directly or through a chain — JSON.stringify() doesn't skip it quietly. It throws:

const node = { name: "root" };
node.self = node;

JSON.stringify(node);
// TypeError: Converting circular structure to JSON

This tends to catch people off guard with things like DOM nodes, certain framework internals, or ORM models that reference their own parent. If you genuinely need to serialize a structure like that, you'll need a custom replacer that tracks visited references, or a library built specifically for that case.

`BigInt` Isn't Supported — At All

JSON.stringify({ total: 10n });
// TypeError: Do not know how to serialize a BigInt

There's no built-in workaround here. If you're working with BigInt, convert it to a Number or String before stringifying.

`Date` Serializes Cleanly, But Doesn't Come Back the Same Way

Thanks to toJSON(), dates convert into ISO strings automatically:

JSON.stringify({ createdAt: new Date() });
// '{"createdAt":"2026-07-30T09:15:00.000Z"}'

The catch: JSON.parse() has no idea that string used to be a Date. You get a plain string back, and if you need real Date behavior again, you have to reconstruct it yourself — which is exactly what the reviver function below is for.

`Map`, `Set`, and Class Instances Don't Serialize the Way You'd Expect

JSON.stringify(new Map([["a", 1]])); // '{}'
JSON.stringify(new Set([1, 2, 3]));  // '{}'

Both come back as empty objects, because JSON.stringify() only looks at enumerable own properties, and neither Map nor Set store their data that way. If you need to serialize either, convert them first:

JSON.stringify(Array.from(myMap.entries()));
JSON.stringify(Array.from(mySet));

Key Order Isn't Always What You Typed

For most objects, JSON.stringify() preserves the order you added keys in. But if any of your keys look like array indexes ("0", "1", "2"), JavaScript sorts those numerically before everything else, regardless of insertion order. It's a small quirk, but it's caused real confusion in code that assumed key order was purely insertion-based.

The Security Gotcha Nobody Mentions

If you're doing server-side rendering and embedding data directly into an HTML <script> tag — a common pattern for hydrating client-side state — there's a real risk hiding in plain sight:

app.get("/", (req, res) => {
  const data = { bio: userInput }; // e.g. "</script><script>alert(1)</script>"

  res.send(`
    <script>
      window.__DATA__ = ${JSON.stringify(data)};
    </script>
  `);
});

If userInput contains </script>, the browser closes your script tag early — and anything after it gets parsed as raw HTML, including a second <script> tag an attacker controls. JSON.stringify() does not escape this for you by default.

The fix is to escape the characters that matter before embedding:

function safeStringify(data) {
  return JSON.stringify(data)
    .replace(/</g, "\\u003c")
    .replace(/>/g, "\\u003e")
    .replace(/\u2028/g, "\\u2028")
    .replace(/\u2029/g, "\\u2029");
}

(The last two handle the Unicode line/paragraph separators, which are valid in JSON strings but invalid inside a JavaScript string literal — another one that's caused real production bugs.) If you're already using something like serialize-javascript on the server, it handles this for you — but it's worth knowing why that step exists rather than treating it as boilerplate.

The "Quick Deep Clone" Trick Has Real Limits

You'll see this pattern used constantly for cloning objects:

const copy = JSON.parse(JSON.stringify(original));

It works fine for flat, plain data — but given everything above, it quietly breaks on dates, undefined values, functions, Map/Set instances, and circular references. In modern JavaScript, there's a better option:

const copy = structuredClone(original);

structuredClone() is built into modern browsers and Node.js 17+, and it correctly handles dates, Map, Set, and circular references — no serialization round-trip required.

Going the Other Direction: `JSON.parse()`

You'll use JSON.parse() just as often as JSON.stringify(), so it's worth covering properly rather than as an afterthought.

The Basics

const raw = '{"name":"Maya","age":29}';
const parsed = JSON.parse(raw);

console.log(parsed.name); // "Maya"

Always Wrap It in `try/catch`

Any time the string comes from outside your code — an API, a file, user input — treat it as untrustworthy. Malformed JSON throws a SyntaxError, and an uncaught one will crash whatever function it's sitting in:

try {
  const data = JSON.parse(userSuppliedString);
} catch (err) {
  console.error("That wasn't valid JSON:", err.message);
}

Rebuilding Types With a Reviver Function

Remember how dates turn into plain strings when they come back through JSON.parse()? A reviver function fixes exactly that:

const raw = '{"createdAt":"2026-07-30T09:15:00.000Z","count":5}';

const parsed = JSON.parse(raw, (key, value) => {
  if (key === "createdAt") return new Date(value);
  return value;
});

console.log(parsed.createdAt instanceof Date); // true

It runs on every key/value pair, bottom-up, letting you rebuild Date objects, class instances, or anything else that got flattened into plain data during serialization.

When You Just Need a Quick, One-Off Conversion

Not every situation calls for opening an editor. Sometimes you've copied JSON from an API response, a bug report, or a teammate's Slack message and simply need to convert it into an escaped string or verify that the output looks correct before using it in code.

While you can always use JSON.stringify() in JavaScript, a browser-based tool can be quicker when you don't want to write a temporary script. For example, this JSON to String Converter lets you paste JSON and instantly see the escaped string output, which is handy for debugging, creating test data, or preparing JSON for configuration files.

`JSON.stringify()` vs. the Alternatives

Method	Output	Handles nested objects?	Notes
`String(obj)` / `${obj}`	`"[object Object]"`	No	Never use this for data — it's not serialization
`obj.toString()`	`"[object Object]"` (unless overridden)	No	Same issue, unless the class defines its own `toString()`
`JSON.stringify(obj)`	Full JSON text	Yes	The correct tool for this job
`util.inspect(obj)` (Node.js)	Formatted, colorized text	Yes	Great for terminal debugging, but not valid JSON — don't send this anywhere

Quick Reference: Best Practices

Always JSON.stringify() before storing or transmitting — localStorage, fetch bodies, and WebSocket messages all expect strings, not live objects.
Always wrap JSON.parse() in try/catch when the source isn't fully trusted.
Use the indentation argument (JSON.stringify(data, null, 2)) for readable logs and debug output.
Use a replacer function to strip sensitive fields before logging or transmitting data.
Give custom classes a toJSON() method if you want predictable, reusable serialization instead of scattering replacer logic everywhere.
Don't rely on JSON.parse(JSON.stringify(x)) for deep cloning — reach for structuredClone() instead.
Escape user-controlled data before embedding JSON in a <script> tag — JSON.stringify() alone isn't safe for that context.
Remember what silently disappears: undefined, functions, and symbols vanish without warning; NaN and Infinity become null; Map and Set serialize as {} unless converted first.

Wrapping Up

JSON.stringify() and JSON.parse() look like two-line utility functions, and most of the time, that's exactly how simple they are to use. The edge cases in this article are the ones that don't show up until you hit them in production — a Date that silently loses its type, a circular reference that crashes a request handler, a password that leaked into a log file because nobody added a replacer.

None of these are hard to avoid once you know they exist. That's really the whole point of writing them down: so the next twenty minutes you'd have spent debugging one of them, you spend building something instead.

If you want to see these behaviors for yourself, the fastest way is to open your browser console right now and run a few of the examples above — especially the circular reference one. Watching it throw is a lot more memorable than reading about it.

Why Your Regex Works in Testing But Breaks in Production

99Tools — Fri, 24 Jul 2026 17:58:02 +0000

You write a regex. You test it against two or three sample strings. It matches perfectly. You ship it.

Three days later, someone opens a bug report titled "validation is broken" and attaches a screenshot that makes no sense to you, because the exact same pattern worked fine when you tried it.

If this has happened to you, you're not bad at regex. You just tested it the way most of us do — against clean, predictable, hand-picked strings. Production doesn't send you clean, predictable, hand-picked strings. It sends you whatever your users, your APIs, and your database actually contain.

Let's go through the specific reasons a regex that passes your tests can still fail in the real world, with examples for each one.

1. Greedy quantifiers eat more than you think

Say you want to strip HTML tags out of a string. You write this:

const stripped = "<div>hello</div>".replace(/<.*>/g, "");
console.log(stripped); // "hello" — looks correct!

You test it, it works, you move on. Then someone passes in real markup with more than one tag on the same line:

const stripped = "<div><span>hello</span></div>".replace(/<.*>/g, "");
console.log(stripped); // "" — everything is gone

.* is greedy by default. It doesn't stop at the first > it finds — it grabs as much as possible and only backs off if the rest of the pattern fails to match. So instead of matching <div> and </div> separately, it matches from the very first < to the very last > in the string, swallowing your actual content along with it.

The fix is usually a lazy quantifier:

"<div><span>hello</span></div>".replace(/<.*?>/g, "");
// "hello" — correct

The bug here isn't that greedy matching is "wrong." It's that your test string only had one tag, so greedy and lazy behaved identically. Real HTML rarely does.

2. Anchors don't mean what you assume across multiline input

^ and $ match the start and end of the string, not the start and end of every line — unless you explicitly tell the engine otherwise.

const log = `INFO: server started
ERROR: connection refused
INFO: retrying`;

const errorLines = log.match(/^ERROR:.*$/g);
console.log(errorLines); // null

This will pass a quick manual test if you only test it against a single-line string like "ERROR: connection refused". It quietly breaks the moment your real input is a multiline log file, config file, or textarea value — which is most of the time in production.

The fix is the m flag:

const errorLines = log.match(/^ERROR:.*$/gm);
console.log(errorLines); // ["ERROR: connection refused"]

If you also need . to match across line breaks (for example, matching a block that spans multiple lines), you need the s flag as well. These two flags get confused for each other constantly, and mixing them up is one of the most common causes of "it matched locally but not on the server."

3. The `/g` flag is stateful, and that will bite you

This one surprises a lot of people who've been writing JavaScript for years.

When you use the g flag with .test() or .exec(), the regex object remembers where it left off via a lastIndex property. If you reuse that same regex object across multiple calls, the results depend on how many times you've already called it.

const re = /foo/g;

console.log(re.test("foo bar")); // true
console.log(re.test("foo bar")); // false! lastIndex is now past the match
console.log(re.test("foo bar")); // true again

Now imagine that regex is defined once at the top of a module and reused to validate items in a loop:

const re = /^\d+$/g;
const ids = ["123", "456", "789"];

ids.forEach(id => {
  console.log(id, re.test(id));
});
// 123 true
// 456 false   <-- wrong, 456 is a perfectly valid match
// 789 true

In testing, you probably ran this once, saw true, and called it done. In production, it runs against a whole array or a whole stream of requests, and every other item mysteriously fails. This exact bug has shipped in real validation logic more than once, because a single test() call in isolation looks completely correct.

The fix: don't reuse a global regex object for independent checks, or reset lastIndex = 0 before each use, or just skip the g flag when you're only checking a single string.

4. Your test data was ASCII. Your users are not.

If your test strings are all plain English letters and numbers, you will never catch encoding and Unicode issues before they reach production.

const nameRegex = /^[a-zA-Z]+$/;

console.log(nameRegex.test("James"));   // true
console.log(nameRegex.test("José"));    // false
console.log(nameRegex.test("张伟"));     // false

If your app has any international users at all, a name field validated this way will reject real, legitimate names. This isn't a rare edge case in production — it's a routine Tuesday for any product with a global user base.

Similarly, character counting gets weird with emoji and other multi-codepoint characters:

const str = "👨‍👩‍👧‍👦";
console.log(str.length); // 11, not 1

That single family emoji is actually made of multiple Unicode code points joined together, and a regex that assumes "one character = one match" will slice right through the middle of it. The u flag helps the engine treat Unicode properly, but it doesn't fix everything on its own — this is genuinely one of the trickier areas of regex, and it's worth testing deliberately rather than assuming.

5. Catastrophic backtracking: fine in dev, a production incident under load

This is the scariest one, because it doesn't show up as "wrong output." It shows up as your server hanging or your CPU spiking.

const evilRegex = /^(a+)+$/;
const badInput = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!";

// This can take an extremely long time to fail
console.log(evilRegex.test(badInput));

Nested quantifiers like (a+)+ can create an explosion of possible ways to backtrack when the string almost-but-not-quite matches. With short test strings, this finishes instantly and you'd never notice a problem. Feed it a longer string that fails near the end, and the number of backtracking paths grows exponentially. This is called ReDoS (Regular Expression Denial of Service), and it's a real, documented cause of production outages — not a theoretical CS-class example.

The practical takeaway: avoid nested repetition where an inner group and an outer group can both match the same characters, and be especially careful with any regex that runs on user-supplied input.

Testing Regex Against Real Conditions, Not Clean Strings

None of these bugs are exotic. They all come from the same root cause: testing a pattern against input that is cleaner and simpler than what production actually sends.

A few practical ways to prevent this:

Test against messy, realistic data. Multiline strings, mixed casing, non-English characters, unusually long inputs, and empty strings should all be part of your test set — not just the happy path.
Test each flag combination deliberately. Avoid adding g or m flags simply because a Stack Overflow thread suggested it — understand exactly how each flag alters your match behavior.
Watch the match happen, not just the final result. Catching a greedy quantifier grabbing too much or an anchor matching the wrong boundary is much easier when you can visualize captured characters instead of just checking a true/false console output. Pasting a pattern into an interactive Regex Tester before submitting a pull request helps you observe highlighted matches update in real time as edge-case inputs are added. This makes greedy-vs-lazy and boundary errors immediately obvious.
Check across engines if your code touches multiple languages. JavaScript, Python, and PCRE (used by PHP and tools like grep) do not share identical syntax support. Lookbehind capability, named group syntax, and flag behavior frequently differ. A regex ported from Python to JavaScript (or vice versa) rarely works identically without adjustments.
Treat user-input regex as a performance risk. Beyond correctness, patterns with nested quantifiers can suffer from severe catastrophic backtracking when processing adversarial input. Always evaluate execution efficiency on edge-case strings.

The short version

Regex bugs in production almost never come from writing the "wrong" pattern. They come from a pattern that's correct for the input you tested and wrong for the input you didn't think to test. Multiline text, non-English characters, repeated calls with a stateful g flag, and unusually long or malformed strings are exactly the kind of input your manual tests tend to skip — and exactly the kind of input production sends you constantly.

Next time you write a pattern, try to break it on purpose before someone else breaks it by accident.

Stop Sending Bloated JSON: A Simple Optimization Every Developer Should Know

99Tools — Wed, 22 Jul 2026 14:07:55 +0000

Open your browser's network tab on almost any API you've built and look at a response payload. Chances are it's pretty-printed — two-space indentation, line breaks after every key, the works. That's great in Postman. It's dead weight on the wire.

This isn't a "you're doing everything wrong" post. Pretty-printed JSON is easier to read, and readability matters during development. The problem is when that same formatting ships to production unchanged, on every request, forever. It's one of those optimizations that takes five minutes and nobody ever gets around to.

What "bloated" actually means here

JSON has no concept of formatting. {"id":1} and the same object spread across five indented lines are semantically identical — the parser doesn't care. Every space, newline, and indentation level in a pretty-printed payload exists purely for human eyes and costs you bytes for no functional reason.

Here's a single object from an API response, formatted the way most frameworks output it by default:

{
  "id": 1,
  "uuid": "9c3f0001-a1b2-4e5f-8c9d-000000000001",
  "name": "Dev Smith",
  "email": "dev.smith@example.com",
  "is_active": false,
  "created_at": "2026-02-08T10:15:00Z",
  "roles": [
    "admin"
  ],
  "address": {
    "street": "693 Main St",
    "city": "Lagos",
    "zip": "21395"
  }
}

That's 303 bytes. Strip the formatting and you get:

{"id":1,"uuid":"9c3f0001-a1b2-4e5f-8c9d-000000000001","name":"Dev Smith","email":"dev.smith@example.com","is_active":false,"created_at":"2026-02-08T10:15:00Z","roles":["admin"],"address":{"street":"693 Main St","city":"Lagos","zip":"21395"}}

241 bytes. Same data, same structure, 20% smaller. For one object that's nothing. Multiply it across a paginated response with 50 objects and it stops being nothing.

Measuring it on a real payload

I generated a realistic API response — a paginated user list, 50 records, each with an id, uuid, email, a roles array, and a nested address object — and measured it three ways: pretty-printed, minified, and both of those gzipped. Here's the actual output:

Pretty-printed JSON size:       19193 bytes
Minified JSON size:             12594 bytes
Bytes saved by minifying alone: 6599 (34.4% smaller)

Pretty-printed JSON, gzipped:   2050 bytes
Minified JSON, gzipped:         1929 bytes
Bytes saved after gzip too:     121 (5.9% smaller)

Read those two blocks together, because the second one is the part most "minify your JSON!" posts skip, and it matters more than the first.

The gzip question

If your API sits behind a server that gzips responses (which, on HTTPS in 2026, is most of them), a huge chunk of that whitespace savings evaporates. Gzip is extremely good at compressing repetitive characters, and indentation is about as repetitive as text gets. In the numbers above, minifying saved 34.4% uncompressed but only 5.9% once gzip was applied to both versions. The compressed minified file was still smaller — just not dramatically.

So the honest answer to "should I minify my JSON?" is: it depends on where compression happens, and whether it happens at all.

Minification still earns its keep in a few specific situations:

Uncompressed responses. Not every endpoint goes through gzip/brotli — internal services, some CDNs with caching quirks, and plenty of misconfigured servers serve JSON uncompressed. Here the 34% isn't theoretical, it's what actually goes over the wire.
WebSocket and real-time messages. permessage-deflate compression exists for WebSockets but isn't always enabled, and a lot of high-frequency message protocols (game state updates, live dashboards, trading data) skip compression entirely because the CPU overhead per tiny message isn't worth it. Minifying costs nothing at send time and shrinks every single frame.
Mobile and constrained networks. Even compressed, smaller is still smaller, and on a flaky connection every byte affects time-to-first-render.
Storage and logging pipelines. If you're storing millions of JSON blobs — event logs, audit trails, cached API responses — the indentation overhead adds up in disk and in what you pay for it, independent of anything that happens over the network.
Before compression runs at all. If you minify before gzip instead of after, you're not fighting compression, you're just feeding it less redundant input. It still helps, it just helps less than the raw number suggests.

Where it barely matters: a typical REST API response served over HTTPS with gzip/brotli already on, where response sizes are in the low kilobytes. You're optimizing 6% of an already-small number. Worth doing if it's free (a one-line config change), not worth an engineering sprint.

How to actually do it

This is the easy part, which is exactly why it's worth doing — the cost is close to zero.

JavaScript / Node — JSON.stringify minifies by default. The formatting you see in dev tools comes from the third argument:

// Pretty (for humans, debugging, config files)
JSON.stringify(data, null, 2);

// Minified (for the wire)
JSON.stringify(data);

If your API framework is pretty-printing responses, it's almost always because someone explicitly configured an indent for development and it never got turned off for production. Check your res.json() / serializer config.

Python:

import json

# Default is already fairly compact, but separators removes the extra space
# after commas and colons that json.dumps adds by default
minified = json.dumps(data, separators=(",", ":"))

Command line, with jq:

jq -c . input.json > output.json

-c is compact output — same data, no formatting.

Quick one-off check. If you just want to quickly strip formatting and test a payload without wiring anything into your build — say, you're debugging an API response on the fly and want to strip whitespace immediately — you can paste it into a browser-based tool like the JSON minifier to collapse it instantly, no setup required. Useful for a quick sanity check before you decide whether it's worth automating in your codebase.

For anything that runs repeatedly — API responses, build artifacts, CI output — automate it at the framework or build-tool level rather than doing it by hand. A one-time manual minify on a static file is fine; a manual step in a deploy pipeline is a bug waiting to happen.

Going further: the array-of-objects problem

Whitespace isn't the only source of bloat. If you have a large array of objects that all share the same keys, you're repeating those key names on every single element — and that repetition survives minification, because the keys are still there.

Same 50-record user list, keys only (id, uuid, name, email, is_active, created_at), compared as an array of objects versus a columnar structure (one array per field, aligned by index):

Row-based (array of objects), minified: 8142 bytes
Columnar (object of arrays), minified:  5506 bytes
Saved: 2636 bytes (32.4% smaller)

That's the classic row-based vs. columnar tradeoff:

// Row-based — key names repeated 50 times
[
  {"id":1,"name":"Dev Smith","is_active":false},
  {"id":2,"name":"Alice Johnson","is_active":true}
]

// Columnar — key names appear once
{
  "id": [1, 2],
  "name": ["Dev Smith", "Alice Johnson"],
  "is_active": [false, true]
}

Interestingly, even gzip didn't fully erase this difference — the compressed columnar version was still about 7.7% smaller than the compressed row-based one in this test, because gzip's window doesn't always catch every repeated key across a large array as efficiently as removing the repetition outright.

This is a real technique used in analytics and data-transfer formats (it's the whole idea behind Arrow and Parquet), but it's a bigger structural change than flipping a minify flag — it breaks the natural "one object per record" shape that most client code expects, so it's worth reaching for only when you're moving genuinely large arrays, not as a default for every endpoint.

Where minification bites you

A few things to watch for before you apply this everywhere:

Don't minify anything a human needs to read or diff. Config files, fixtures, seed data, anything committed to git — keep those pretty-printed. A minified config file that breaks in production is miserable to debug, and a minified JSON file in a pull request makes every diff useless.
It doesn't fix ambiguous data. Duplicate keys in an object, inconsistent types across an array, deeply nested structures that should've been flattened — minifying changes byte count, not data quality. If your JSON has structural problems, minifying just makes them smaller and harder to spot.
Comments aren't valid JSON either way. If you're relying on // comments in a .json file for documentation, that's actually JSON5 or JSONC, not JSON — a different problem than formatting, but worth knowing minification tools won't preserve those comments if you run them against a strict JSON parser.
Logs are for reading later. If you're minifying application logs to save disk space, fine — but make sure whatever reads them back (log viewer, jq, alerting rules) can still parse compact JSON. Most can; some older tooling assumes one key-value pair per line.

The actual checklist

Production API responses: minify. It's a one-line config change in most frameworks, so there's little reason not to, even where gzip is already doing most of the work.
Real-time / WebSocket / streaming messages: minify, especially if compression isn't enabled on that channel.
Config files, fixtures, anything committed to source control: keep pretty-printed.
Large arrays of uniform objects moving significant data: consider a columnar structure, but only when the size actually justifies the added complexity on the receiving end.
Before optimizing further: check whether gzip/brotli is even on. If it's off, turning it on will usually save you more than minification alone, and the two aren't mutually exclusive — do both.

None of this is exotic. It's a serializer setting, an output flag, or in the worst case a five-minute script — the kind of change that's easy to skip because it never feels urgent, right up until someone finally looks at what's actually going over the wire.

Markdown isn't just for documentation—it's the backbone of clean, portable, and AI-friendly content. Learn the essential Markdown best practices every developer should follow, plus the tools that help enforce consistency and save time.

99Tools — Mon, 22 Jun 2026 14:18:50 +0000

99Tools

Jun 22

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

#markdown #webdev #productivity #beginners

7 min read

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

99Tools — Mon, 22 Jun 2026 14:17:09 +0000

You already know Markdown.

You use it every day — in README files, GitHub issues, pull requests, documentation, and blog posts. It's everywhere in the developer world.

But here's the thing: most developers write functional Markdown. It renders. It works. But it's not always clean, consistent, or easy for teammates to read in its raw form.

And raw readability matters more than people realise. Your teammates read it in code review. Your future self reads it six months later. CI tools parse it. Inconsistent formatting causes real problems — broken renders, messy diffs, and documentation that slowly becomes a mess to maintain.

This guide covers the Markdown practices that actually make a difference. Not just the basics — but the specific habits that separate good documentation from great documentation.

Let's get into it.

Why Markdown formatting standards matter

Before diving in, let me explain why this is worth caring about.

Markdown has no single universal specification that all tools agree on. GitHub uses GitHub Flavored Markdown (GFM). VS Code defaults to CommonMark. dev.to has its own rendering quirks. Notion handles things differently again.

The same .md file can render differently depending on where you open it.

The best defence against this? Write clean, consistent, unambiguous Markdown. Follow the conventions. Use tools to enforce them.

It's the same reason we use Prettier for JavaScript. You stop thinking about formatting and just write — the tooling handles the rest.

1. Use ATX-style headings (with a space after #)

There are two heading styles in Markdown. ATX uses # symbols. Setext uses underlines (=== or ---).

Always use ATX. It's cleaner, more readable, and supported everywhere.

<!-- ✅ Do this -->
## My Section Heading

<!-- ❌ Not this -->
My Section Heading
------------------

Also — always put a space between the # and your heading text. Some parsers require it. Others don't. But the space is specified in the CommonMark spec, so it's the safest habit.

<!-- ✅ Correct -->
## Introduction

<!-- ❌ Risky -->
##Introduction

One more rule: never skip heading levels. Go H1 → H2 → H3 in sequence. Jumping from H1 directly to H4 breaks screen readers and makes your document structure confusing to navigate.

2. Always specify a language in fenced code blocks

Whenever you write a fenced code block, add a language identifier.

<!-- ✅ Do this -->

javascript
const greet = (name) => Hello, ${name}!;


<!-- ❌ Not this -->

javascript
const greet = (name) => Hello, ${name}!;

markdown

Why does it matter?

Syntax highlighting activates
Readers immediately know what they're looking at
Documentation generators use it for formatting and indexing
Screen readers can announce the language type

Common language identifiers: javascript, typescript, python, bash, json, yaml, sql, css, html, go, rust.

Use lowercase by convention. javascript is standard. JavaScript works in most parsers, but it's not consistent.

3. Keep list markers consistent

Unordered lists accept -, *, or + as markers. Pick one and use it throughout the entire document.

The most widely recommended choice is -.

<!-- ✅ Consistent — do this -->
- First item
- Second item
- Third item

<!-- ❌ Inconsistent — avoid this -->
- First item
* Second item
+ Third item

Mixing markers isn't just visually messy. Some parsers treat different markers as separate lists entirely, which breaks the rendered output.

For ordered lists, use 1. for every item rather than incrementing manually. If you insert or reorder items later, the numbering stays correct automatically.

<!-- ✅ Easier to reorder -->
1. Install dependencies
1. Configure the environment
1. Start the server

<!-- Rendered output is still: 1, 2, 3 -->

4. Add blank lines around block elements

This is one of the most common mistakes in Markdown files. Block elements — headings, code blocks, lists, blockquotes — need blank lines before and after them.

Without blank lines, some parsers get confused and produce unexpected output.

<!-- ❌ Missing blank lines — risky -->
Here's some intro text.
## Section Heading
More text here.
- Item one
- Item two
Some conclusion.

<!-- ✅ Properly spaced -->
Here's some intro text.

## Section Heading

More text here.

- Item one
- Item two

Some conclusion.

The raw file becomes far more readable too. When someone scans a .md file in a terminal or basic text editor, the spacing makes the structure obvious at a glance.

5. Write descriptive link text — not "click here"

This is a writing best practice as much as a Markdown one. But it shows up constantly in developer docs.

<!-- ❌ Tells the reader nothing -->
For more information, [click here](https://example.com/docs).

<!-- ✅ Tells the reader exactly where they're going -->
See the [official API documentation](https://example.com/docs) for details.

Descriptive link text matters for three reasons:

Accessibility — screen readers announce link text out of context. "Click here" is meaningless when read aloud in a list of links.
SEO — anchor text signals to search engines what the linked page is about.
Scannability — readers can understand the link's destination without stopping to click it.

Make your link text describe the destination, not the action.

6. Wrap technical terms in inline code

Any time you mention a function name, variable, file path, command, or technical term in prose — wrap it in backticks.

<!-- ❌ Technical terms blend into the text -->
Run npm install in the root directory, then open the config.js file.

<!-- ✅ Technical terms stand out immediately -->
Run `npm install` in the root directory, then open `config.js`.

This is one of those small habits that has a big impact on readability. Technical terms pop out visually. Readers can immediately tell "this is something I need to type or pay attention to" versus surrounding explanation.

7. Use blockquotes for the right things

Blockquotes are for quoting external content, adding important notes, or creating callouts. They're not for indentation or visual decoration.

<!-- ✅ Good use — an actual callout -->
> **Note:** This configuration only applies to production environments.

<!-- ❌ Misuse — this is just prose, not a quote -->
> This section explains how to set up your project.

On GitHub, you can use the alert syntax for proper callout blocks. It's more semantic and renders with distinct styling:

> [!NOTE]
> Highlights information the reader should take into account when skimming.

> [!WARNING]
> Critical content that demands immediate attention.

> [!TIP]
> Optional information to help the reader be more successful.

These render as styled, colour-coded callout boxes on GitHub — much cleaner than the old bold-in-a-blockquote approach. Use them in README files and documentation pages.

8. Align table pipes for raw readability

Markdown tables are notoriously awkward to write by hand. The pipes rarely line up, and the raw file becomes painful to read.

<!-- ❌ Valid, but hard to read in raw form -->
|Name|Role|Status|
|--|--|--|
|Alice|Developer|Active|
|Bob|Designer|Active|

<!-- ✅ Clean and readable even before rendering -->
| Name  | Role      | Status |
|-------|-----------|--------|
| Alice | Developer | Active |
| Bob   | Designer  | Active |

Both render identically. But the second version is readable in a code review, a terminal, or a plain text editor — places where your Markdown lives before it gets rendered.

Aligning pipes manually every time is tedious. A Markdown formatter does it instantly — paste your document in, get back clean, consistently formatted Markdown with aligned tables, proper spacing, and normalised list markers.

9. Use reference-style links for long URLs

When URLs are long, inline links clutter the prose and make it hard to read.

<!-- ❌ The URL overwhelms the sentence -->
See the [deployment guide](https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3) before going live.

<!-- ✅ The prose stays clean -->
See the [deployment guide][deploy] before going live.

[deploy]: https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3

Reference-style links work like footnotes. The prose reads naturally, and all the URLs sit at the bottom of the file where they're easy to update without touching the text.

This pays off especially in long documentation files where the same link appears multiple times.

10. End files with a single newline

This one's subtle but matters for git hygiene.

Every text file — including .md files — should end with exactly one newline character. Most editors do this automatically, but not all.

Without a trailing newline:

Git shows a \ No newline at end of file warning in diffs
Diffs become noisy in pull requests
Some POSIX tools behave unexpectedly when reading the file

In VS Code, enable this automatically with "files.insertFinalNewline": true in your settings. Most other editors have an equivalent option.

Tools that enforce all of this automatically

Reading these practices is useful. Remembering every single one while you're writing — less so.

The practical move is to integrate enforcement into your workflow so you don't have to think about it.

For teams and CI pipelines:

markdownlint — the most widely used Markdown linter. Available as a CLI, a VS Code extension, and a GitHub Action. Enforces rules like heading hierarchy, code block languages, and list consistency. Configurable with a .markdownlint.json file.
Prettier — if your team already runs Prettier on code, it handles Markdown too. Good for enforcing consistent prose wrapping and spacing.
remark — a powerful Markdown processor with a rich plugin ecosystem. Useful when you need to both lint and programmatically transform Markdown files.

For individual workflow:

The fastest option is to run your Markdown through a formatter before you commit or publish. It catches the things you'd otherwise miss — a missed blank line, an unspecified code block language, misaligned table pipes — without requiring any setup.

Quick reference

Practice	What to do
Headings	ATX style (`#`), space after `#`, don't skip levels
Code blocks	Always specify the language identifier
Lists	Use `-` for unordered; `1.` for all ordered items
Spacing	Blank lines before and after all block elements
Links	Descriptive anchor text, not "click here"
Inline code	Backticks for all technical terms, commands, filenames
Blockquotes	Only for actual quotes or callouts
Tables	Align pipes so the raw file is readable
Long URLs	Reference-style links to keep prose clean
File ending	One trailing newline character

Final thoughts

Markdown is deceptively simple. The basics take minutes to learn. But clean, consistent Markdown — readable in both raw and rendered form — takes deliberate habits.

The good news: most of this can be automated. Add markdownlint to your editor. Set up a GitHub Action to check Markdown on every pull request. Run docs through a formatter before you publish.

Set the standard once. Enforce it automatically. Then spend your energy on writing content worth reading.

What Markdown practices has your team standardised on? Drop a comment — I'd love to know what's working.

Think your JSON is valid? Think again. 🚨 From trailing commas to invalid data types, these are the 10 JSON mistakes developers hit most often—and the exact fixes to avoid hours of debugging. Save this guide for your next API project. 👇

99Tools — Tue, 09 Jun 2026 04:29:48 +0000

99Tools

Jun 8

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

#json #webdev #javascript #programming

11 min read

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

99Tools — Mon, 08 Jun 2026 12:31:32 +0000

JSON looks simple — just key-value pairs, right? But its strictness is legendary. No trailing commas. No comments. No single quotes. No undefined. Miss one rule and your entire payload is dead on arrival.

Even senior developers get caught by these. Not because they don't know JSON — because the spec is unforgiving in ways that feel arbitrary until you understand why those rules exist.

This article covers the 10 most common JSON errors, why they happen, and exactly how to fix them — with real-world code examples, not toy snippets.

Quick Reference Table

#	Error	The Fix
1	Trailing commas	Remove the last comma in arrays/objects
2	Single quotes	Use double quotes `"` for all keys and values
3	`undefined` / `NaN` / `Infinity`	Replace with `null` or a valid number
4	Unescaped special characters	Escape `"`, `\`, and control chars in strings
5	Mismatched brackets	Lint your JSON before sending
6	Comments in JSON	Strip comments; use JSON5 if you need them
7	Wrong data types	Validate types at the boundary — never silently coerce
8	Circular references	Use a replacer function or the `flatted` library
9	Date objects	Store as ISO strings; parse explicitly on the way out
10	Large integers	Use strings or `BigInt` for numbers > 2⁵³ − 1

Why Does JSON Keep Tripping Developers Up?

JSON was designed as a minimal, language-agnostic data format. That minimalism is intentional — but it means there's almost zero forgiveness baked in.

Unlike JavaScript (which has semicolon insertion, loose equality, and other guardrails), JSON has zero tolerance for syntax deviations.

The other issue: most JSON errors surface at runtime — often in production, often deep inside a third-party API response you didn't write. Editor linting helps, but it can't catch errors in dynamically generated payloads.

That's what this guide is for.

Error #1: Trailing Commas That Kill Your Parser

What's happening

A trailing comma is a comma after the last item in an array or object. JavaScript has allowed this since ES5. JSON absolutely does not.

The error you'll see

SyntaxError: Unexpected token } in JSON at position 42

❌ Wrong

{
  "user": {
    "name": "Priya Kapoor",
    "role": "admin",
    "permissions": ["read", "write", "delete",]
  },
}

Two trailing commas here: after "delete" and after the closing } of user.

✅ Fixed

{
  "user": {
    "name": "Priya Kapoor",
    "role": "admin",
    "permissions": ["read", "write", "delete"]
  }
}

Remove the last comma from every array and object. Most JSON linters flag this instantly.

💡 Pro tip: Never hand-edit minified JSON. Always pretty-print first (JSON.stringify(obj, null, 2)), edit, then re-minify. The structure is visible and trailing commas are easy to catch.

Error #2: Single Quotes Instead of Double Quotes

What's happening

JavaScript lets you use single quotes, double quotes, or backticks for strings. JSON only allows double quotes — for both keys and string values.

The error you'll see

SyntaxError: Unexpected token ' in JSON at position 0

❌ Wrong

{
  'endpoint': '/api/v2/orders',
  'timeout': '30s'
}

✅ Fixed

{
  "endpoint": "/api/v2/orders",
  "timeout": "30s"
}

The sneaky variant

This bites developers who copy a JavaScript object literal and paste it into a JSON file:

// Valid JS object literal
const config = {
  host: 'localhost',
  port: 5432
}

That object has unquoted keys — which is also invalid JSON, even if you swap in double quotes. Both the key format and the string delimiters need to change.

💡 Pro tip: If you accept JSON from users or external systems, always wrap JSON.parse() in a try/catch. Never assume the format is correct.

Error #3: `undefined`, `NaN`, and `Infinity` Aren't Valid JSON

What's happening

JavaScript has special values — undefined, NaN, Infinity, -Infinity — that simply don't exist in the JSON spec. When you serialize an object containing these, JSON.stringify() silently drops or converts them.

The error you'll see

No error. That's the problem. The values just vanish silently.

const payload = {
  userId: 42,
  score: NaN,
  bonus: Infinity,
  metadata: undefined
};

console.log(JSON.stringify(payload));
// {"userId":42,"score":null,"bonus":null}
// ⚠️ metadata key is gone entirely

❌ Wrong

const stats = {
  avgResponseTime: totalTime / requestCount, // 💥 NaN if requestCount === 0
  maxRetries: Infinity
};

fetch('/api/stats', {
  method: 'POST',
  body: JSON.stringify(stats)
});
// Server receives: {"avgResponseTime":null,"maxRetries":null}

✅ Fixed

function sanitizeForJSON(value) {
  if (typeof value !== 'number') return value;
  if (Number.isNaN(value) || !Number.isFinite(value)) return null;
  return value;
}

const stats = {
  avgResponseTime: sanitizeForJSON(totalTime / requestCount) ?? 0,
  maxRetries: 100 // Use a real cap, not Infinity
};

Or use a replacer with JSON.stringify:

const safeStringify = (obj) =>
  JSON.stringify(obj, (key, value) => {
    if (typeof value === 'number' && !Number.isFinite(value)) return null;
    if (value === undefined) return null;
    return value;
  });

💡 Pro tip: JSON.stringify also silently drops functions and Symbol values. If your object might contain these, validate the output or use a schema validator like zod or ajv before sending.

Error #4: Unescaped Special Characters in Strings

What's happening

Certain characters inside JSON strings must be escaped with a backslash. The most common culprits: double quotes, backslashes, and control characters like newlines and tabs.

The error you'll see

SyntaxError: Bad escaped character in JSON at position 34

Or a subtler one — a string that ends prematurely because an unescaped " closes it early.

❌ Wrong

{
  "message": "He said "hello" and left",
  "filePath": "C:\Users\priya\documents\report.pdf",
  "notes": "First line
Second line"
}

Three problems here:

Unescaped " inside a string
Unescaped backslashes in the Windows path
Literal newline inside a string

✅ Fixed

{
  "message": "He said \"hello\" and left",
  "filePath": "C:\\Users\\priya\\documents\\report.pdf",
  "notes": "First line\nSecond line"
}

Full escape reference:

Character	Escaped
`"`	`\"`
`\`	`\\`
Newline	`\n`
Tab	`\t`
Carriage return	`\r`
Unicode	`\uXXXX`

The golden rule for dynamic JSON

If you're building JSON strings from user input, always use JSON.stringify() — never concatenate strings manually:

// ❌ Never do this — JSON injection + XSS risk
const json = `{"message": "${userInput}"}`;

// ✅ Do this
const json = JSON.stringify({ message: userInput });

💡 Pro tip: Windows file paths are the #1 source of unescaped backslash bugs. If you're storing paths in JSON config files, always double-escape them or use forward slashes — Windows accepts both.

Error #5: Mismatched Brackets or Braces

What's happening

Every { needs a }. Every [ needs a ]. In long or deeply nested JSON, a missing bracket is easy to introduce and hard to spot manually.

The error you'll see

SyntaxError: Unexpected end of JSON input

SyntaxError: Expected ',' or '}' after property value in JSON at position 312

❌ Wrong

{
  "pipeline": {
    "stages": [
      {
        "name": "build",
        "steps": ["install", "compile", "test"
      },
      {
        "name": "deploy",
        "steps": ["push", "restart"]
      }
    ]
  }
}

The steps array in the first stage is missing its closing ].

✅ Fixed

{
  "pipeline": {
    "stages": [
      {
        "name": "build",
        "steps": ["install", "compile", "test"]
      },
      {
        "name": "deploy",
        "steps": ["push", "restart"]
      }
    ]
  }
}

How to find it fast

Paste your JSON into an online JSON formatter — it highlights exactly which line the error is on and pretty-prints your JSON so the structure is obvious. You can also run a quick check in Node:

node -e "JSON.parse(require('fs').readFileSync('config.json', 'utf8'))" && echo "Valid"

Or use jq:

cat data.json | jq .

💡 Pro tip: When writing large JSON by hand, add both the opening and closing bracket before filling in the contents. Same principle as closing HTML tags immediately — far less error-prone than adding the closer after 30 lines of content.

Error #6: Comments in JSON — The Feature That Doesn't Exist

What's happening

Developers coming from JavaScript, Python, or YAML naturally try to add comments to JSON config files. JSON has no comment syntax. None. Not //, not /* */, not #.

The error you'll see

SyntaxError: Unexpected token / in JSON at position 2

❌ Wrong

{
  // Database connection settings
  "host": "db.internal.example.com",
  "port": 5432, /* default Postgres port */
  "poolSize": 10 # max concurrent connections
}

✅ Fix option 1: Remove comments

{
  "host": "db.internal.example.com",
  "port": 5432,
  "poolSize": 10
}

✅ Fix option 2: Use a `_comment` convention

Some teams use a dedicated key for inline documentation:

{
  "_comment": "Database settings — see runbook for rotation procedure",
  "host": "db.internal.example.com",
  "port": 5432,
  "poolSize": 10
}

Not elegant, but it parses cleanly and is searchable.

✅ Fix option 3: Switch to JSON5 or JSONC

If you control the parsing (e.g., a config file for your own tool), use JSON5 or JSONC:

import JSON5 from 'json5';

const config = JSON5.parse(`{
  // Database connection
  host: "db.internal.example.com",
  port: 5432,
}`);

💡 Pro tip: tsconfig.json, .eslintrc.json, and VS Code's settings.json all silently support comments even though they use .json — VS Code's parser strips them. Don't let this fool you into thinking regular JSON.parse() handles them. It won't.

Error #7: Incorrect Data Types Causing Silent Failures

What's happening

JSON supports six types: strings, numbers, booleans, arrays, objects, and null. The problem isn't usually an invalid type — it's passing the right value in the wrong type, especially numbers as strings or booleans as strings.

The error you'll see

No parsing error at all. You get a logic bug — comparisons fail, math returns NaN, or an API returns a cryptic 400 Bad Request.

❌ Wrong

// HTML form data — everything comes back as strings
const formData = {
  userId: "1042",      // Should be a number
  isAdmin: "false",    // Should be a boolean — but "false" is truthy!
  retryCount: "3"      // Should be a number
};

// On the receiving end:
if (data.isAdmin) {
  // "false" is a non-empty string → truthy → this ALWAYS runs!
  grantAdminAccess(data.userId); // 💥 Security bug
}

✅ Fixed

const formData = {
  userId: parseInt(form.userId.value, 10),
  isAdmin: form.isAdmin.checked,  // boolean from checkbox
  retryCount: Number(form.retryCount.value)
};

Or validate and coerce at the boundary with zod:

import { z } from 'zod';

const UserSchema = z.object({
  userId: z.coerce.number().int().positive(),
  isAdmin: z.boolean(),
  retryCount: z.coerce.number().int().min(0).max(10)
});

const parsed = UserSchema.parse(rawFormData);
// Throws a detailed error if types don't match after coercion

💡 Pro tip: The "false" string bug is particularly dangerous. In JavaScript, every non-empty string is truthy — if ("false") evaluates to true. Always use strict boolean types when the value will be used in a conditional.

Error #8: Circular References When Serializing Objects

What's happening

A circular reference is when an object contains a reference back to itself (directly or through a chain). JSON.stringify() throws immediately when it encounters one.

The error you'll see

TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    |     property 'parent' -> object with constructor 'Object'
    --- property 'child' closes the circle

How it happens in the wild

const order = {
  id: "ORD-9821",
  customer: { name: "Alex Mensah" }
};

order.self = order; // Circular reference!
JSON.stringify(order); // 💥 TypeError

DOM nodes, Express req/res objects, and Sequelize/Mongoose model instances are full of these.

✅ Fix option 1: Use a replacer to skip circular refs

function safeStringify(obj) {
  const seen = new WeakSet();
  return JSON.stringify(obj, (key, value) => {
    if (typeof value === 'object' && value !== null) {
      if (seen.has(value)) return '[Circular]';
      seen.add(value);
    }
    return value;
  });
}

console.log(safeStringify(order));
// {"id":"ORD-9821","customer":{...},"self":"[Circular]"}

✅ Fix option 2: Use the `flatted` library for full round-trip support

import { stringify, parse } from 'flatted';

const json = stringify(order);   // Handles circular refs
const restored = parse(json);    // Restores the circular structure

✅ Fix option 3: Serialize only what you need

// Instead of serializing the whole ORM instance:
const orderForAPI = {
  id: order.id,
  customerName: order.customer.name,
  items: order.items.map(i => ({ sku: i.sku, qty: i.quantity }))
};

JSON.stringify(orderForAPI); // Clean, no circular refs

💡 Pro tip: This error is extremely common when logging Express request objects in error handlers. Never do logger.info(JSON.stringify(req)). Log req.method, req.url, req.headers, and req.body individually instead.

Error #9: Date Objects — The Serialization Trap

What's happening

JSON.stringify() converts Date objects to ISO 8601 strings automatically. But JSON.parse() does not convert them back. You get a plain string — silently, every time.

The error you'll see

No error at parse time. But later:

const event = JSON.parse(JSON.stringify({ createdAt: new Date() }));

console.log(typeof event.createdAt);    // "string" — not a Date!
console.log(event.createdAt.getTime()); // TypeError: event.createdAt.getTime is not a function

❌ Wrong pattern

const meeting = {
  title: "Sprint Planning",
  scheduledAt: new Date("2025-06-10T09:00:00Z"),
  duration: 60
};

const stored = JSON.stringify(meeting);
const restored = JSON.parse(stored);

// This silently fails — string vs number comparison is NaN
if (restored.scheduledAt > Date.now()) {
  sendReminder(); // Never called
}

✅ Fixed

const restored = JSON.parse(stored);

// Option 1: Parse manually
restored.scheduledAt = new Date(restored.scheduledAt);

// Option 2: Use a reviver function
const restoredSafe = JSON.parse(stored, (key, value) => {
  if (typeof value === 'string' && /^\d{4}-\d{2}-\d{2}T/.test(value)) {
    return new Date(value);
  }
  return value;
});

// Option 3: Use date-fns
import { parseISO } from 'date-fns';
const scheduledAt = parseISO(restored.scheduledAt);

💡 Pro tip: The cleanest architecture is to never store Date objects in state that crosses a serialization boundary. Use ISO strings throughout your app and only convert to Date when you actually need .getTime(), .toLocaleString(), etc.

Error #10: Large Integers and Precision Loss

What's happening

JavaScript uses 64-bit floating point (IEEE 754) for all numbers. The maximum safe integer is 2⁵³ − 1 (Number.MAX_SAFE_INTEGER = 9007199254740991). Any integer larger than this cannot be represented exactly — and JSON parsing silently rounds it.

The error you'll see

No error. Just silently wrong data:

const response = `{"id": 9007199254740993, "userId": 92233720368547758}`;

const parsed = JSON.parse(response);
console.log(parsed.id);     // 9007199254740992 — off by 1!
console.log(parsed.userId); // 92233720368547760 — completely wrong!

This is a real problem with PostgreSQL 64-bit IDs, Twitter/X Snowflake IDs, and distributed systems.

✅ Fix option 1: Use strings for large IDs

The Twitter/X API famously added an id_str field alongside id for this exact reason:

{
  "id": 9007199254740993,
  "id_str": "9007199254740993",
  "text": "JSON precision bugs are the worst"
}

Always use id_str in client code.

✅ Fix option 2: Pre-process with a regex before parsing

function parseBigInts(jsonString) {
  return JSON.parse(
    jsonString.replace(
      /(":\s*)(-?\d{17,})/g,
      (_, prefix, num) => `${prefix}"${num}"`
    )
  );
}

const safe = parseBigInts(`{"snowflakeId": 927349827349827349}`);
console.log(safe.snowflakeId); // "927349827349827349" — exact string

✅ Fix option 3: Use the `json-bigint` library

import JSONBig from 'json-bigint';

const parsed = JSONBig.parse(`{"id": 9007199254740993}`);
console.log(parsed.id); // 9007199254740993n — a real BigInt

💡 Pro tip: This bug only manifests for IDs large enough to exceed MAX_SAFE_INTEGER. Your test data (IDs like 1, 42, 1001) will never trigger it. It only hits in production. Always verify your ID generation strategy before assuming small numbers.

Debugging Toolkit

When you're staring at a broken JSON payload, here's your workflow:

1. Validate in Node

node -e "JSON.parse(require('fs').readFileSync('config.json', 'utf8'))" && echo "Valid"

2. Pretty-print with Python (no dependencies)

echo '{"a":1,"b":[1,2,3]}' | python3 -m json.tool

3. Validate + query with jq

cat data.json | jq .

4. Validate in your CI/CD pipeline

# In your package.json scripts:
"validate:config": "node -e \"JSON.parse(require('fs').readFileSync('./config.json'))\"",

Quick Reference Cheat Sheet

JSON CHEAT SHEET
══════════════════════════════════════════════════════════════

  SYNTAX RULES                      VALID TYPES
  ─────────────────────────────     ───────────────────────
  ✅ Double quotes only             String:   "hello"
  ✅ No trailing commas             Number:   42, 3.14
  ✅ No comments                    Boolean:  true, false
  ✅ Balanced brackets/braces       Null:     null
  ✅ Keys must be strings           Array:    [1, 2, 3]
                                    Object:   {"k": "v"}

  INVALID VALUES (use null instead)
  ─────────────────────────────────
  ❌ undefined   ❌ NaN   ❌ Infinity   ❌ Functions

  ESCAPE SEQUENCES IN STRINGS
  ─────────────────────────────────
  \"  →  "       \\  →  \       \n  →  newline
  \t  →  tab     \r  →  carriage return
  \uXXXX  →  Unicode character

  SPECIAL CASES TO WATCH FOR
  ─────────────────────────────────
  • Dates        → Store as ISO strings; parse explicitly
  • Big ints     → Use strings for IDs > 9007199254740991
  • Circular refs → Use replacer or flatted library
  • Type coercion → "false" ≠ false; "3" ≠ 3

══════════════════════════════════════════════════════════════

Wrapping Up

JSON errors almost always fall into one of two camps:

Syntax errors — trailing commas, wrong quotes, missing brackets. These are the easiest to fix. A good linter catches them before you run a single line of code. Add JSON validation to your editor, run JSON.parse() inside try/catch everywhere you accept external data.
Semantic traps — Dates that lose their type, integers that lose precision, undefined that silently vanishes. These are trickier because they don't throw errors — they silently corrupt your data. The fix is validation at the boundary using zod, ajv, or even a careful manual check before you trust the output of JSON.parse().

The patterns that burn developers the most are #3 (NaN/undefined disappearing silently), #9 (Dates becoming strings), and #10 (large integers rounding). If you add nothing else to your workflow, add a JSON schema validator at every API boundary.

Which of these has bitten you hardest? My personal nemesis is #9 — every single time. Drop the error number in the comments.

FAQ Schema Markup Generators: What They Actually Do (and What They Don't Tell You)

99Tools — Sat, 23 May 2026 09:09:33 +0000

So you've heard that adding FAQ schema to your pages can get you those sweet rich results in Google Search — the expandable Q&A dropdowns right in the SERP. You Google "FAQ schema generator", paste in your questions, copy the JSON-LD, and drop it in your <head>. Done, right?

Sort of. There's more going on here than most tutorials explain.

Let's break it down properly.

What Is FAQ Schema, Actually?

FAQ schema is a type of structured data — machine-readable metadata you embed in your HTML to tell search engines what kind of content is on your page.

It uses the schema.org/FAQPage vocabulary and is typically written in JSON-LD (JavaScript Object Notation for Linked Data), which Google officially recommends over Microdata or RDFa for new implementations.

A minimal, valid FAQ schema block looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is structured data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Structured data is a standardized format for providing information about a page and classifying the page content."
      }
    }
  ]
}
</script>

The mainEntity array holds your questions. Each item is a Question with a name (the question text) and an acceptedAnswer containing an Answer with a text property.

That's the whole spec for this type. Not complicated — which is exactly why generators exist.

What Do FAQ Schema Generators Actually Do?

A FAQ Schema generator is just a UI wrapper around a template. You fill in fields, it writes the JSON-LD for you. Nothing more.

The output of every single FAQ schema generator in existence looks like the block above. They differ only in:

Whether they let you add multiple Q&A pairs (most do)
Whether the text field allows HTML (more on this in a second)
Whether they validate the output before showing it to you
Whether they minify or pretty-print the JSON

They do not:

Check if your questions match actual content on your page
Verify whether your page is eligible for rich results
Guarantee you'll get a rich snippet
Update automatically if you change your FAQ content

That last point trips people up constantly.

The HTML-in-answers Question

Google's documentation says the text property of an Answer does support a limited subset of HTML — specifically: <a>, <b>, <br>, <em>, <i>, <li>, <ol>, <strong>, <ul>.

Some generators strip all HTML from the answer field. Some preserve it. Some encode it incorrectly (double-escaping & instead of &, breaking the output).

If your answers need links or lists inside them, test your generator's output manually. Paste the result into Google's Rich Results Test and inspect what it actually parses.

Common Mistakes the Generator Won't Catch

1. Schema that doesn't match your visible content

Google's guidelines are explicit: your structured data must reflect content that is visually present on the page. If you generate FAQ schema for questions that only exist in the JSON-LD and not in the actual HTML — that's a violation, and Google can apply a manual action to your site.

Don't use generators to add "bonus" FAQs that aren't rendered on the page.

2. Using FAQPage on pages that aren't really FAQ pages

FAQPage is for pages where the primary purpose is answering questions. Dropping FAQ schema on a product page, a blog post, or a homepage just because you have one accordion component at the bottom is a gray area that Google has increasingly penalized.

3. Duplicate FAQ schema across multiple pages

If you have the same FAQ block on 50 pages (common with CMS templates), search engines see it as low-quality repeated content in structured data. Each FAQ schema implementation should be page-specific.

4. Stale schema after content edits

You updated the FAQ section on your page, but the JSON-LD in the <head> still has the old questions. Now your schema and your content disagree. Generators produce static output — you're responsible for keeping it in sync.

The Right Way to Use a Generator

Think of generators as scaffolding tools, not end-to-end solutions. Here's a sane workflow:

Write your FAQ content on the page first. Real questions, real answers, visible in the HTML.
Use a generator to produce the initial JSON-LD from that content.
Validate the output using Google's Rich Results Test.
Embed it — either inline in a <script> tag or injected via your CMS/tag manager.
Tie it to your content update process so the schema stays in sync.

For anything more than a few static pages, consider templating the schema generation into your build pipeline or CMS rather than relying on a one-off generator.

Validating Your Output

Two tools worth bookmarking:

Google Rich Results Test — tests whether Google can parse your schema and whether your page is eligible for rich results
Schema.org Validator — validates against the schema.org spec directly, independent of Google's interpretation

These aren't interchangeable. Google's validator tells you what Google will do with your schema. The schema.org validator tells you if your markup is technically correct per the open standard. Run both.

When Rich Results Don't Appear (and It's Not the Generator's Fault)

Even perfectly valid FAQ schema doesn't guarantee a rich result. Google treats rich results as optional enhancements, not entitlements. Common reasons you won't see them:

The page doesn't have enough authority or trust signals yet
Google already shows a competitor's FAQ snippet for the same queries
The SERP layout for those queries doesn't include FAQ features (Google has been reducing FAQ rich results for high-authority sites since 2023)
The page was crawled but not yet re-indexed since you added the schema

Structured data is an input signal to Google's rendering pipeline. What comes out the other end is Google's decision.

TL;DR

Thing	What It Does	What It Doesn't Do
FAQ Schema Generator	Writes valid JSON-LD for you	Validates content match, guarantees rich results
JSON-LD in `<head>`	Makes schema parseable by crawlers	Make questions visible to users
Google Rich Results Test	Shows if schema is parseable	Guarantees SERP appearance
FAQPage schema type	Signals Q&A structure to search engines	Work on pages without actual FAQ content

Structured data is one of those areas where the tooling is simple but the judgment required to use it correctly is non-trivial. Generators handle the syntax. Understanding when and how to apply the schema — that part is still on you.

Stop Writing Ugly SQL: A Developer's Guide to Clean, Readable Queries

99Tools — Tue, 19 May 2026 13:35:04 +0000

We've all been there. You open a PR, and the SQL query looks like someone sneezed on the keyboard:

select u.id,u.name,u.email,o.total,o.created_at from users u join orders o on u.id=o.user_id where o.status='completed' and o.created_at >= '2024-01-01' order by o.created_at desc limit 50

It works. It returns the right data. But it's a nightmare to review, debug, or extend.

SQL readability is not a cosmetic concern — it's an engineering discipline. Messy SQL leads to logic errors, missed optimizations, and silent bugs that survive code review because nobody wants to untangle the mess.

This guide walks through the conventions, habits, and formatting rules that make SQL a joy to work with.

Why SQL Formatting Matters More Than You Think

Unlike application code, SQL queries often live in multiple places simultaneously — inside ORM raw query methods, migration files, stored procedures, BI tools, and debug logs. A single ugly query might be read by:

A backend engineer debugging a slow endpoint
A DBA optimizing an index
A data analyst trying to understand business logic
You, six months from now, at 11pm before a deploy

Consistent formatting makes all of these scenarios less painful.

The Core Rules

1. Capitalize SQL keywords

SQL keywords should be uppercase. Column names, table names, and aliases should be lowercase (or match your schema's convention).

Bad:

select id, name from users where active = true

Good:

SELECT id, name
FROM users
WHERE active = true

This instantly distinguishes SQL structure from your data model.

2. One clause per line

Every major clause — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT — gets its own line. No exceptions.

Bad:

SELECT u.id, u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.created_at >= '2023-01-01' GROUP BY u.id, u.name HAVING COUNT(o.id) > 5 ORDER BY order_count DESC

Good:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at >= '2023-01-01'
GROUP BY
    u.id,
    u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC

The second version can be scanned in seconds. The first requires active decoding.

3. Align your columns in the SELECT list

Put each selected column on its own line, indented consistently (2 or 4 spaces — pick one and stick to it):

SELECT
    account_id,
    account_name,
    region,
    plan_type,
    created_at
FROM accounts
WHERE status = 'active'

This makes it trivial to add, remove, or reorder columns during development.

4. Qualify every column name in joins

Once you have more than one table in a query, always prefix columns with their table alias. Never leave a reader guessing which table id or created_at belongs to.

Ambiguous:

SELECT id, name, total, created_at
FROM users
JOIN orders ON users.id = orders.user_id

Clear:

SELECT
    u.id,
    u.name,
    o.total,
    o.created_at
FROM users u
JOIN orders o ON u.id = o.user_id

This also protects you when schema changes add a new column with a conflicting name — your query won't silently start returning the wrong data.

5. Write meaningful aliases

Single-letter aliases like a, b, x are lazy and harmful. Use short but meaningful abbreviations.

-- Bad
SELECT a.name, b.total
FROM accounts a
JOIN invoices b ON a.id = b.account_id

-- Good
SELECT acc.name, inv.total
FROM accounts acc
JOIN invoices inv ON acc.id = inv.account_id

6. Put JOIN conditions on a separate, indented line (for complex joins)

When join conditions are multi-part or involve expressions, break them out clearly:

SELECT
    p.id,
    p.title,
    c.body AS latest_comment
FROM posts p
LEFT JOIN comments c
    ON c.post_id = p.id
    AND c.created_at = (
        SELECT MAX(created_at)
        FROM comments
        WHERE post_id = p.id
    )
WHERE p.published = true

7. Use CTEs to break up complexity

Common Table Expressions (CTEs) are one of the most underused tools in SQL. Instead of nesting subqueries three levels deep, break the logic into named, readable steps.

Subquery hell:

SELECT avg_revenue, cohort
FROM (
    SELECT cohort, AVG(revenue) AS avg_revenue
    FROM (
        SELECT
            DATE_TRUNC('month', first_purchase_date) AS cohort,
            SUM(order_total) AS revenue
        FROM (
            SELECT u.id, MIN(o.created_at) AS first_purchase_date, o.total AS order_total
            FROM users u
            JOIN orders o ON u.id = o.user_id
            GROUP BY u.id, o.total
        ) user_orders
        GROUP BY cohort
    ) cohort_revenue
    GROUP BY cohort
) final
ORDER BY cohort

CTE version:

WITH user_first_purchase AS (
    SELECT
        u.id AS user_id,
        MIN(o.created_at) AS first_purchase_date
    FROM users u
    JOIN orders o ON u.id = o.user_id
    GROUP BY u.id
),

cohort_revenue AS (
    SELECT
        DATE_TRUNC('month', ufp.first_purchase_date) AS cohort,
        SUM(o.total) AS revenue
    FROM user_first_purchase ufp
    JOIN orders o ON ufp.user_id = o.user_id
    GROUP BY cohort
),

cohort_averages AS (
    SELECT
        cohort,
        AVG(revenue) AS avg_revenue
    FROM cohort_revenue
    GROUP BY cohort
)

SELECT
    cohort,
    avg_revenue
FROM cohort_averages
ORDER BY cohort

The CTE version is longer but infinitely more debuggable. You can run each CTE independently to validate intermediate results. This matters enormously in production debugging.

8. Comment non-obvious logic

SQL is often used for business logic that isn't apparent from the data alone. Comment that context directly in the query.

SELECT
    customer_id,
    SUM(order_total) AS lifetime_value
FROM orders
WHERE
    -- Exclude test orders created by the QA team's shared account
    customer_id != 9999
    -- Only count orders after the platform migration (older data is unreliable)
    AND created_at >= '2022-06-01'
GROUP BY customer_id
HAVING SUM(order_total) > 0

Future you will be grateful.

Refactoring a Real Query: Before and After

Here's a realistic before/after from a production analytics query:

Before:

select u.id,count(distinct s.id) as sessions,count(distinct e.id) as events,max(s.started_at) as last_seen from users u left join sessions s on s.user_id=u.id and s.started_at>now()-interval '30 days' left join events e on e.session_id=s.id and e.type not in ('pageview','heartbeat') where u.plan='pro' and u.deleted_at is null group by u.id having count(distinct s.id)>0 order by sessions desc limit 100

After:

SELECT
    u.id,
    COUNT(DISTINCT s.id)  AS sessions,
    COUNT(DISTINCT e.id)  AS events,
    MAX(s.started_at)     AS last_seen
FROM users u
LEFT JOIN sessions s
    ON s.user_id = u.id
    AND s.started_at > NOW() - INTERVAL '30 days'
LEFT JOIN events e
    ON e.session_id = s.id
    -- Exclude low-signal event types from engagement count
    AND e.type NOT IN ('pageview', 'heartbeat')
WHERE
    u.plan = 'pro'
    AND u.deleted_at IS NULL
GROUP BY u.id
HAVING COUNT(DISTINCT s.id) > 0
ORDER BY sessions DESC
LIMIT 100

Same query. Completely different readability. The second version makes the intent, filters, and join logic obvious at a glance.

Tooling: Format First, Then Review

If you're working with legacy SQL or reviewing someone else's query, formatting it first before reading it is one of the highest-ROI habits you can build. A well-formatted query reveals its structure — and its bugs.

For quick formatting without leaving your browser, this SQL formatter handles most SQL dialects and produces consistently indented, readable output in one click. It's especially useful when you inherit a minified query from a log file or a BI tool export and need to understand it quickly.

For integrating formatting into your dev workflow, the sql-formatter npm package is excellent — it supports PostgreSQL, MySQL, SQLite, BigQuery, and more, and you can hook it into Prettier or a pre-commit check.

Conventions Worth Standardizing Across Your Team

If you're working in a team, agree on these and write them down:

Convention	Recommended Default
Keyword casing	`UPPERCASE`
Identifier casing	`snake_case` (match your schema)
Indentation	4 spaces
Alias style	Short abbreviation, not single letter
Column per line	Always in `SELECT` with 3+ columns
CTE preference	Always over 2+ levels of subquery nesting

Enforcing these via a linter (e.g. SQLFluff) rather than hoping for consistency is even better — SQLFluff supports dozens of dialects and integrates with CI pipelines cleanly.

Quick Reference Cheat Sheet

-- ✅ Correct structure
WITH cte_name AS (
    SELECT
        column_one,
        column_two,
        column_three
    FROM table_name tn
    JOIN other_table ot ON tn.id = ot.table_id
    WHERE tn.some_condition = true
)

SELECT
    c.column_one,
    c.column_two,
    c.column_three,
    COUNT(t.id) AS related_count
FROM cte_name c
LEFT JOIN third_table t ON c.column_one = t.foreign_key
GROUP BY
    c.column_one,
    c.column_two,
    c.column_three
ORDER BY c.column_one ASC
LIMIT 1000

Final Thoughts

SQL style isn't about personal preference — it's about the next person (including yourself) who has to read, debug, or extend your query under pressure. Clean SQL is a form of documentation.

The conventions here are not the only valid choices. What matters is consistency. Pick a style, document it, and automate enforcement where possible.

If you have conventions or habits that have saved you in production, drop them in the comments — I'd love to see what others have standardized.

Most devs send the whole object and call it a PATCH. RFC 6902 exists for a reason. Here's what JSON Patch actually does and when it's worth the switch.

99Tools — Mon, 11 May 2026 16:51:45 +0000

99Tools

May 11

Stop sending entire objects in your PATCH requests. There's a better way

#javascript #json #webdev #api

3 min read

Stop sending entire objects in your PATCH requests. There's a better way

99Tools — Mon, 11 May 2026 16:49:43 +0000

I'll be honest — I spent years writing PATCH endpoints that just took the whole object and merged it server-side. You probably have too. It works. Until it doesn't.

You get concurrent edits. You get race conditions. You get a client that sends { "role": null } because it forgot to exclude the field. And your "partial update" is silently nuking data.

Then I found RFC 6902 — JSON Patch. And it solved exactly this problem in a way I hadn't thought about.

What JSON Patch actually is

Instead of sending the new version of an object, you send a description of the changes. A list of operations: what to add, remove, replace, move.

Here's the difference in practice:

❌ The old way — send the whole thing

PATCH /users/42
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

✅ With JSON Patch — send only what changed

PATCH /users/42
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/role", "value": "admin" },
  { "op": "replace", "path": "/preferences/theme", "value": "dark" }
]

Two fields changed. Two operations. Nothing else touched.

The six operations

[
  { "op": "add",     "path": "/tags/0",    "value": "urgent"  },
  { "op": "remove",  "path": "/draft"                         },
  { "op": "replace", "path": "/status",    "value": "active"  },
  { "op": "move",    "from": "/tmp/name",  "path": "/name"    },
  { "op": "copy",    "from": "/template",  "path": "/doc"     },
  { "op": "test",    "path": "/version",   "value": 3         }
]

The test op is the one most people ignore. It fails the whole patch if the value at the path doesn't match — which gives you optimistic locking for free. If /version isn't 3, nothing gets applied. That's huge for concurrent edits.

A real-world scenario

Imagine a collaborative config editor. Two users open the same document. User A changes the timeout. User B changes the retry count. With a full-object PUT, whoever saves last wins and overwrites the other's change.

With JSON Patch + test:

[
  { "op": "test",    "path": "/version",  "value": 7    },
  { "op": "replace", "path": "/timeout",  "value": 5000 }
]

If someone else already committed and bumped the version to 8, this patch fails with a 409. The client knows to re-fetch and retry. Clean, explicit, auditable.

The diff problem — and how I handle it

The annoying part is writing patches by hand. When you're prototyping or debugging, you just want to paste two JSON states and see what changed.

The compare() output is exactly what a JSON Patch generator produces — a minimal array of ops describing the diff between two states. In production, you generate this programmatically. During prototyping, you're usually diffing by hand to understand what your code should be producing.

For production use, you don't write patches manually — you generate them programmatically from a diff.

Libraries worth knowing

For JavaScript/Node.js, fast-json-patch is the go-to:

import * as jsonpatch from 'fast-json-patch';

const before = { name: "Alice", role: "user" };
const after  = { name: "Alice", role: "admin" };

const patch = jsonpatch.compare(before, after);
// [{ op: "replace", path: "/role", value: "admin" }]

const result = jsonpatch.applyPatch(before, patch).newDocument;

For Python, jsonpatch works the same way — make_patch() to diff, apply() to execute.

Things that will bite you

JSON Pointer paths (RFC 6901) use / as separator. A key containing a slash or tilde must be escaped: ~ → ~0, / → ~1. This silently fails if you forget.
Array indices are fragile. /items/2 means the third element right now — if the array shifts between diff and apply, you're patching the wrong element. - as index means "append", which is usually safer.
Skip the test op and you lose the main concurrency benefit. It's optional in the spec, but you probably want it in any multi-user scenario.

When should you actually use this?

Honestly, not everything needs JSON Patch. If you're building a simple CRUD app with a single user, PATCH with a partial object is fine. JSON Patch earns its complexity when you have: concurrent editors, audit logs that need to record exactly what changed, sync protocols (think CRDTs, OT), or large objects where sending the whole thing is wasteful.

If any of those apply — it's worth the RFC read.

Are you using JSON Patch in production? I'm curious how people handle the array index fragility problem specifically — do you use stable IDs in your patch paths, or do you diff differently? Drop it in the comments 👇

DEV Community: 99Tools

Think JSON.stringify() is simple? Think again. Learn how JSON to String conversion really works, avoid common mistakes, handle edge cases, and write cleaner JavaScript with practical examples you can use today.

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

TL;DR

First, Let's Clear Up the Terminology

The Wrong Way (and Why It Fails)

The Core Method: JSON.stringify()

Making Output Readable: The Indentation Argument

Controlling What Gets Included: The Replacer

Custom Serialization With toJSON()

Where You'll Actually Use This

Storing Data in localStorage or sessionStorage

Sending Data With fetch()

Logging and Debugging

Comparing or Hashing Objects

The Gotchas (Learned the Hard Way)

Some Values Just Disappear

NaN and Infinity Become null

Circular References Throw

BigInt Isn't Supported — At All

Date Serializes Cleanly, But Doesn't Come Back the Same Way

Map, Set, and Class Instances Don't Serialize the Way You'd Expect

Key Order Isn't Always What You Typed

The Security Gotcha Nobody Mentions

The "Quick Deep Clone" Trick Has Real Limits

Going the Other Direction: JSON.parse()

The Basics

Always Wrap It in try/catch

Rebuilding Types With a Reviver Function

When You Just Need a Quick, One-Off Conversion

JSON.stringify() vs. the Alternatives

Quick Reference: Best Practices

Wrapping Up

Why Your Regex Works in Testing But Breaks in Production

1. Greedy quantifiers eat more than you think

2. Anchors don't mean what you assume across multiline input

3. The /g flag is stateful, and that will bite you

4. Your test data was ASCII. Your users are not.

5. Catastrophic backtracking: fine in dev, a production incident under load

Testing Regex Against Real Conditions, Not Clean Strings

The short version

Stop Sending Bloated JSON: A Simple Optimization Every Developer Should Know

What "bloated" actually means here

Measuring it on a real payload

The gzip question

How to actually do it

Going further: the array-of-objects problem

Where minification bites you

The actual checklist

Markdown isn't just for documentation—it's the backbone of clean, portable, and AI-friendly content. Learn the essential Markdown best practices every developer should follow, plus the tools that help enforce consistency and save time.

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

Why Markdown formatting standards matter

1. Use ATX-style headings (with a space after #)

2. Always specify a language in fenced code blocks

3. Keep list markers consistent

4. Add blank lines around block elements

5. Write descriptive link text — not "click here"

6. Wrap technical terms in inline code

7. Use blockquotes for the right things

8. Align table pipes for raw readability

9. Use reference-style links for long URLs

10. End files with a single newline

Tools that enforce all of this automatically

Quick reference

Final thoughts

Think your JSON is valid? Think again. 🚨 From trailing commas to invalid data types, these are the 10 JSON mistakes developers hit most often—and the exact fixes to avoid hours of debugging. Save this guide for your next API project. 👇

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

Quick Reference Table

Why Does JSON Keep Tripping Developers Up?

Error #1: Trailing Commas That Kill Your Parser

What's happening

The error you'll see

❌ Wrong

✅ Fixed

Error #2: Single Quotes Instead of Double Quotes

What's happening

The error you'll see

The Core Method: `JSON.stringify()`

Custom Serialization With `toJSON()`

Storing Data in `localStorage` or `sessionStorage`

Sending Data With `fetch()`

`NaN` and `Infinity` Become `null`

`BigInt` Isn't Supported — At All

`Date` Serializes Cleanly, But Doesn't Come Back the Same Way

`Map`, `Set`, and Class Instances Don't Serialize the Way You'd Expect

Going the Other Direction: `JSON.parse()`

Always Wrap It in `try/catch`

`JSON.stringify()` vs. the Alternatives

3. The `/g` flag is stateful, and that will bite you

Error #3: `undefined`, `NaN`, and `Infinity` Aren't Valid JSON

✅ Fix option 2: Use a `_comment` convention

✅ Fix option 2: Use the `flatted` library for full round-trip support

✅ Fix option 3: Use the `json-bigint` library