I spend probably 30% of my workday staring at JSON. API responses, config files, database exports, log payloads -- it is everywhere. Over the years I have built up a mental toolkit for dealing with it, and most of it boils down to three things: validating early, formatting for humans, and converting between formats without losing your mind.
Why JSON Took Over
JSON won because it is simple. Douglas Crockford didn't really invent it so much as document what JavaScript was already doing. Two data structures -- objects (key-value pairs) and arrays (ordered lists) -- and six value types: strings, numbers, booleans, null, objects, and arrays. That is the entire specification. No schemas required, no namespaces, no processing instructions. You can read a JSON file and immediately understand the shape of the data.
Compare that to XML, which needs closing tags, attributes vs. elements decisions, CDATA sections, and often a DTD or XSD schema just to get started. JSON's simplicity is exactly why REST APIs adopted it almost universally.
Validation: Catching Problems Before They Cascade
The most common JSON error I see in the wild is a trailing comma. JavaScript allows trailing commas in objects and arrays, but JSON does not. This trips up developers constantly, especially when copy-pasting from JS code into a .json config file.
// INVALID - trailing comma
{"name": "Alice", "age": 30,}
// VALID
{"name": "Alice", "age": 30}
Other frequent mistakes include single quotes instead of double quotes, unquoted keys, and comments. JSON has no comment syntax at all -- this surprises a lot of people coming from JavaScript or YAML. A good validator catches all of these instantly and tells you exactly which line has the problem.
My personal rule: validate JSON before doing anything else with it. It takes two seconds and prevents the kind of debugging session where you spend an hour chasing a bug that turns out to be a missing quotation mark on line 47.
Formatting: Making JSON Human-Readable
APIs almost always return minified JSON -- everything on a single line with no whitespace. Machines process it fine, but human eyes need structure. Good formatting adds indentation and line breaks so you can actually see the nesting at a glance.
The standard convention is 2-space indentation. Some teams prefer 4 spaces or tabs, but 2 spaces has become the de facto norm in web development. Most formatters let you choose.
Beyond basic pretty-printing, a few things I always look for in a formatter: the ability to sort keys alphabetically (great for comparing two objects side by side), collapsible sections for deeply nested data, and syntax highlighting that distinguishes strings from numbers from booleans at a glance. Color-coded JSON is dramatically easier to scan than monochrome text, especially when you are hunting for a specific value inside a 500-line response body.
JSON to CSV: Flattening Nested Data
This conversion comes up constantly. You have API data in JSON, but your stakeholder wants it in a spreadsheet. The challenge is that JSON is hierarchical and CSV is flat. Nested objects need to be flattened, and arrays need to be handled somehow -- either as repeated rows, comma-separated values in a cell, or separate columns.
There is no single "correct" way to flatten JSON to CSV. The right approach depends entirely on what you plan to do with the CSV afterward. For simple objects with no nesting, the conversion is trivial. For deeply nested structures with arrays of arrays, you will want to think about your flattening strategy before you start.
XML to JSON: The Legacy Migration
If you have worked with enterprise APIs or SOAP services, you know XML intimately. Converting XML to JSON is mostly straightforward, but attributes are the tricky part. XML elements can have both attributes and child content simultaneously. JSON has no concept of attributes -- everything is simply a key-value pair.
The common convention is to prefix attribute names with "@" in the JSON output, so <book isbn="123"> becomes {"book": {"@isbn": "123"}}. It is not the prettiest notation, but it preserves all the information without any ambiguity.
YAML to JSON: Config File Translation
YAML is popular for configuration files because it feels more human-friendly than JSON -- no curly braces, no commas, and it supports comments natively. Kubernetes manifests, Docker Compose files, GitHub Actions workflows, and countless other tools rely on YAML.
But YAML's flexibility has a dark side. Indentation is significant (like Python), and there are surprising edge cases. For example, the bare value no is interpreted as boolean false in YAML 1.1. Many developers have been burned by country codes like "NO" (Norway) being silently converted to a boolean. Always verify that types came through correctly when converting between YAML and JSON.
Practical Tips I Use Daily
- Always validate before parsing. A quick validation step saves you from cryptic runtime errors downstream.
- Use a formatter with syntax highlighting. Color-coded JSON is dramatically easier to scan than monochrome text.
- Check for encoding issues. Non-ASCII characters in JSON must be properly escaped, or the file must be saved as UTF-8.
- Bookmark your converter tools. Switching between JSON, CSV, XML, and YAML is a daily task for most developers. Having reliable tools on hand eliminates friction.
- Know the limits of each format. JSON cannot represent dates natively. CSV loses type information. XML is verbose but self-describing. YAML is powerful but sensitive to whitespace errors.