Every developer has pasted a minified API response into a formatter and stared at one long line, wondering where the nesting went wrong. I built a client-side JSON formatter to solve that exact moment, and the work taught me more about JSON than years of casually using it. Disclosure first: I built this tool — it is part of ToolkitLoop, my collection of free browser tools — so this post is both a tutorial and a build log.
Here are the five lessons, each with code you can run today.
1. JSON is stricter than JavaScript, and that is the point
JavaScript lets you write {name: 'Alex', active: True,} and nobody complains until you try to parse it as JSON. JSON does not allow unquoted keys, single-quoted strings, Python-style booleans, trailing commas, or comments. Each of those is a feature of some other language, not a bug in your data — but JSON rejects all of them.
The core formatting operation is just two lines:
const data = JSON.parse(rawText);
const pretty = JSON.stringify(data, null, 2);
JSON.parse enforces the strict rules. JSON.stringify with an indent of 2 produces the readable output. Everything else in a formatter — the tree view, the search box, the repair button — is help around those two lines. When you understand that, debugging gets simpler: if JSON.parse throws, the document is invalid, full stop. No formatter setting will change that fact; only fixing the text will.
A practical habit follows from this: keep your parse and your repair separate. Parse first to learn whether the document is valid. Repair only when you know exactly which predictable mistake you are fixing. Mixing the two steps hides the error you most need to see.
2. Safe repair means a small, honest list
The most tempting feature in a formatter is an aggressive "fix everything" button. I resisted it, and here is why: a repair that guesses can silently change meaning. If a tool invents a missing field, reorders data, or converts a type to make parsing succeed, you may ship a document that parses cleanly and behaves wrongly.
The repair list I kept is deliberately small and predictable:
- trailing commas removed
- single-quoted strings converted to double quotes
- simple unquoted keys quoted
- True, False, and None converted to true, false, and null
- comments stripped
- common AI code fences stripped That is it. Each item is a copy-and-paste mistake with one obvious correction. Anything outside that list stays an error, and the user sees the error instead of a silent guess. The tool page says this plainly: review repaired output before using it in production. That sentence is not legal padding. It is the contract that makes automatic repair trustworthy. Try it with the classic broken example:
// Input (invalid JSON)
const broken = `{
name: 'Alex',
active: True,
}`;
// After limited repair, this parses:
const fixed = `{
"name": "Alex",
"active": true
}`;
console.log(JSON.parse(fixed));
// { name: 'Alex', active: true }
Notice what did not change: the values, the field names, and the order. A good repair preserves all three.
3. Readability is a debugging tool, not cosmetics
Formatting is often treated as tidying up, but for JSON it is genuinely a debugging step. A minified response hides nesting errors. An indented response shows them. When every field sits on its own line, a field under the wrong parent jumps out. When a tree view lets you collapse a branch, you can check one subtree without losing your place in a thousand-line document.
Two reading aids earn their place in any formatter. First, a tree view: it turns a flat wall of text into collapsible structure, which matters most when a response contains nested arrays of objects. Second, a key search: it answers "where is the error code in this response?" without manual scanning. Neither changes the data. Both change how fast you find a problem.
Indentation choice matters less than consistency. Two spaces is the common default, but matching your project's style matters more than the number itself. A formatted document pasted back with the wrong indentation creates a noisy diff that hides the real change. Format with your project's indent, then copy.
You can try the workflow here: JSON Formatter (https://toolkitloop.com/json-formatter). Paste a response, format it, switch to the tree view, and search for one key. The whole loop takes under a minute, and it is the loop I use when an API response does not look right.
4. Never upload data you would not paste into a chat
This is the lesson that changed how I think about tool architecture. A server-side formatter receives your text, processes it, and returns a result. For public sample data, that is harmless. For a production API response, a config file, or an AI answer containing project details, that round trip creates a copy of your data somewhere else — in transit, in a log, or in a processor you do not control.
A client-side formatter avoids that round trip entirely. The tool page puts it simply: everything stays in this browser, and the text is not uploaded to ToolkitLoop. That design choice removes a whole class of exposure, and it costs nothing in features for formatting, validation, repair, tree viewing, or search. All of those run in JavaScript on your device.
That does not make any formatter a vault. My rule, and the rule I recommend, is the same for every online tool: redact real secrets before you paste. Replace an API key with REDACTED, format the document, check the structure, and put the real value back only in your own secure system. Local processing plus redaction is a much stronger combination than either habit alone.
If you take one habit from this post, take that one. The next time you are about to paste a production response into a random formatter, pause and ask: does this tool need to receive my data at all? For formatting, the answer is no.
5. Syntax is not schema, and confusing them wastes hours
A document can be perfectly valid JSON and still be rejected by your API. That is not a contradiction. JSON syntax answers one question: does this text follow JSON's punctuation and value rules? A JSON Schema answers a different question: does this data match the expected contract — required fields, permitted types, allowed values, and formats?
The formatter validates syntax and helps you inspect shape. It does not claim to validate a JSON Schema, and that distinction is stated on the tool page for a reason. When a clean document is rejected, the debugging order should be:
- Format and confirm the syntax is valid.
- Check the schema: is a required field missing?
- Check types: is a number where a string is expected, or vice versa?
- Check values: is a status outside the allowed list? Skipping step 2 and re-formatting the same document five times is a familiar waste of time. I have watched developers do it, and I have done it myself. Naming the two checks separately — syntax first, schema second — ends that loop. The companion tool makes the split explicit: the formatter makes valid JSON readable and repairs a few common mistakes, while the JSON Validator focuses on finding and explaining syntax errors. Use validation when you do not know why a document fails. Use formatting when you know it is valid and just cannot read it.
Putting it together
The full workflow is short enough to remember:
- Redact secrets, then paste.
- Parse to learn whether the document is valid.
- Repair only the small predictable list, then review the output.
- Format with your project's indentation.
- Read the result once, checking parents, closures, and types.
- If a clean document is still rejected, check the schema, not the syntax. That is the whole tutorial, and it is also the design of the tool: format, validate, and fix JSON in your browser (https://toolkitloop.com/json-formatter). Free, no signup, and your text never leaves your device. Disclosure again, because it matters: I built this tool, so I am biased toward client-side design. Try the workflow on your own ugliest API response and judge it by the result, not by this post. What is your rule for pasting production data into online tools — redact first, use local tools only, or something else? I am curious where other developers draw the line.
Top comments (1)
구문 파싱과 제한적인 복구, 스키마 검증을 분리한 흐름이 명확하네요. 복구 전후의 변경 지점을 함께 보여주고 원문으로 돌아갈 수 있게 하면, 단일 따옴표나 주석을 고치는 과정에서 값의 의미가 달라지지 않았는지 검토하기 더 좋겠습니다.