JSON Formatter: What Is JSON and How to Format JSON Correctly
If you've ever pasted an API response into a text editor and seen one giant, unreadable line of curly braces and quotes, you already know why JSON formatting matters. JSON (JavaScript Object Notation) is the format almost every API, config file, and web app uses to move data around — and reading it in its raw, unformatted form is genuinely hard on the eyes. This guide explains what JSON actually is, how its syntax works, the mistakes that break it most often, and how to use Kravoy's JSON Formatter to go from a wall of text to something you can actually debug.
What Is JSON?
JSON stands for JavaScript Object Notation. It's a lightweight, text-based format for representing structured data — objects, lists, numbers, text, true/false values, and null. Despite the name, it's not tied to JavaScript: JSON is language-independent, and every mainstream programming language (Python, Java, PHP, Go, C#, Ruby) has built-in or standard-library support for reading and writing it.
What makes JSON so widely used is that it's both easy for humans to read and easy for machines to parse. There's no ambiguity in its grammar — a JSON parser either accepts a document or rejects it, with no gray area — which is exactly what makes strict syntax rules (covered below) non-negotiable rather than a style preference.
Where JSON Is Used
JSON shows up in more places than most people realize:
- APIs — the overwhelming majority of REST and GraphQL APIs send and receive JSON. When you call an API and get data back, it's almost always JSON.
- Configuration files — package.json, tsconfig.json, VS Code settings, and countless other tool configs are JSON.
- Data storage — many databases (MongoDB, PostgreSQL's JSONB columns) store documents natively in JSON or a JSON-like format.
- Browser storage and state — localStorage values, saved app state, and data passed between a frontend and backend are routinely JSON.
- Log files and webhooks — structured logs and webhook payloads (Stripe, GitHub, Slack) are typically JSON.
If you write software or work with data in any capacity, you will run into raw JSON regularly — which is exactly when a formatter earns its keep.
JSON Objects: The Core Building Block
A JSON object is a collection of key-value pairs, wrapped in curly braces { }. Each key is a string in double quotes, followed by a colon, then a value:
{
"name": "Sarah Johnson",
"age": 29,
"isActive": true
}Keys must always be double-quoted strings — this is one of the most common sources of "invalid JSON" errors, covered in detail below. Multiple key-value pairs are separated by commas, and the last pair has no trailing comma.
JSON Arrays: Ordered Lists of Values
A JSON array is an ordered list of values, wrapped in square brackets [ ]:
{
"colors": ["red", "green", "blue"],
"scores": [88, 92, 76, 100]
}Array items don't have to be the same type — a single array can mix strings, numbers, objects, and even other arrays — though in practice, well-designed APIs usually keep each array consistent (e.g., an array of user objects, all with the same shape).
The Six Data Types JSON Supports
JSON has exactly six value types, and understanding them precisely helps you spot invalid data at a glance:
- String — text wrapped in double quotes: "hello". Single quotes are not valid JSON.
- Number — integers or decimals, written without quotes: 42, 3.14, -7. JSON has no separate "integer" vs "float" type — it's just "number."
- Boolean — true or false, lowercase, unquoted.
- Null — null, lowercase, unquoted, representing "no value."
- Object — a { }-wrapped collection of key-value pairs (can be nested).
- Array — a [ ]-wrapped ordered list (can be nested).
Notably absent: dates, functions, comments, and undefined. None of these are valid JSON values — a date is always represented as a string (e.g., ISO 8601 format like "2026-09-17T10:00:00Z"), and there's no way to write a comment inside a JSON document at all, which surprises a lot of people coming from JavaScript.
Nested JSON: Objects and Arrays Inside Each Other
Real-world JSON is rarely flat — objects contain arrays, arrays contain objects, and this can nest several levels deep. Here's a realistic example, the kind of response you might get from a user-profile API:
{
"id": 4821,
"username": "sarah_dev",
"email": "sarah@example.com",
"isVerified": true,
"address": {
"city": "Austin",
"state": "Texas",
"zipCode": "78701"
},
"roles": ["editor", "moderator"],
"orders": [
{
"orderId": "ORD-1001",
"total": 2499.5,
"items": [
{
"sku": "TSHIRT-BLK-M",
"qty": 2
},
{
"sku": "MUG-WHT",
"qty": 1
}
]
}
],
"lastLogin": "2026-09-10T08:15:00Z",
"referredBy": null
}This is exactly the kind of structure that's manageable when formatted with indentation, and nearly impossible to trace by eye when minified onto a single line — which is the whole reason formatting matters once JSON gets past a handful of fields.
Valid vs Invalid JSON
JSON has a strict, unforgiving grammar. A document is either 100% valid or it fails to parse — there's no "mostly correct." Here's a side-by-side comparison of the same data, valid and invalid:
Valid:
{
"product": "Wireless Mouse",
"price": 899,
"inStock": true,
"tags": ["electronics", "accessories"]
}Invalid (single quotes, unquoted key, trailing comma):
{
product: 'Wireless Mouse',
"price": 899,
"inStock": true,
"tags": ["electronics", "accessories",]
}The second block looks almost identical at a glance, and would run fine as a plain JavaScript object literal — but it is not valid JSON, and any strict JSON parser (including JSON.parse() and Kravoy's formatter) will reject it. This gap between "looks like JSON" and "is JSON" is where most real-world debugging time goes.
Common JSON Syntax Errors (and How to Spot Them)
These five mistakes account for the vast majority of "invalid JSON" errors:
- Missing commas between key-value pairs or array items:{ "a": 1 "b": 2 }Missing the comma after "a": 1. Every pair except the last needs a trailing comma.
- Single quotes instead of double quotes:{'name': 'Alex'}JSON requires double quotes for both keys and string values — single quotes are valid in JavaScript object literals but not in JSON.
- Missing quotation marks around keys:{name: "Alex"}Unlike JavaScript, JSON keys must always be quoted strings, with no exceptions.
- Trailing commas after the last item:{"a": 1, "b": 2,}JSON does not allow a comma after the final key-value pair or the final array item — this trips up developers coming from languages/formats that do allow it.
- Mismatched or missing brackets — an opening { without a closing }, or a [ closed with a } instead of ]. These are especially easy to introduce by hand-editing deeply nested JSON, and easy to miss by eye — but a formatter/validator catches them immediately, since it has to successfully match every bracket to parse at all.
Other errors worth knowing: unescaped special characters inside a string (a literal double quote or newline inside a string value needs to be escaped as \" or \n), and leading zeros or a trailing decimal point in numbers (01 and 1. are both invalid JSON numbers).
Minified vs Formatted JSON
Minified JSON strips all unnecessary whitespace, producing the smallest possible file size — this is what APIs send over the wire, since every extra byte adds up at scale:
{"id":4821,"username":"sarah_dev","roles":["editor","moderator"],"referredBy":null}Formatted (pretty-printed) JSON adds indentation and line breaks so the structure is visible at a glance:
{
"id": 4821,
"username": "sarah_dev",
"roles": ["editor", "moderator"],
"referredBy": null
}Both represent identical data — formatting is purely cosmetic and has zero effect on what the JSON means to a parser. But for a human trying to find a specific field, debug a broken response, or understand a config file's structure, the difference between these two is the difference between a two-second scan and several minutes of squinting at commas.
Why Developers Format JSON
A few concrete reasons formatting isn't just a nicety:
- Debugging API responses. When an API call returns something unexpected, a formatted, indented view makes it immediately obvious which field is missing, null, or has the wrong type — buried in a minified string, that same problem can take minutes to spot.
- Reviewing config files. Config files like package.json or CI pipeline definitions get hand-edited constantly; consistent indentation makes merge conflicts and diffs readable.
- Validating before you trust it. Formatting and validating are really the same operation — a formatter can only indent JSON it successfully parsed, so the act of formatting doubles as a correctness check before you paste that JSON into code, a request body, or a database.
- Communicating with teammates. Pasting formatted JSON into a bug report, Slack message, or pull request comment is far easier for a reviewer to actually read than a single 4,000-character line.
How to Format JSON with Kravoy's JSON Formatter
Kravoy's JSON Formatter runs entirely in your browser — nothing you paste is uploaded anywhere, which matters if you're debugging a response that contains real user data or internal API details. Here's the workflow:
- Paste your JSON into the input panel on the left. This can be a full API response, a config file, or anything else in JSON format.
- Check the validity instantly. If the JSON is invalid, an error message appears directly under the input telling you what's wrong (for example, an unexpected token at a specific position) — you don't need to guess which bracket or comma is the problem.
- View the formatted result. Once valid, the right panel shows your data two ways: a collapsible Tree view for exploring nested structures (handy for large responses where you want to collapse sections you don't care about), and a Text view showing the fully indented JSON as plain text.
- Choose your indentation. Switch between 2 spaces, 4 spaces, or tabs depending on your project's style — the formatted output updates immediately.
- Minify when you need the opposite. The Minify button strips all whitespace back out, useful when you need to paste compact JSON into a config value or a size-constrained field.
- Copy or download the result. Use the copy icon (or the Ctrl+Shift+C shortcut) to grab the formatted text, or download it directly as a .json file.
Because validation and formatting happen in the same step, this doubles as a fast way to answer "is this JSON actually valid?" before you paste it somewhere that matters — a request body, a config file, or a bug report.
Related Tools for Working with API Data
JSON formatting is rarely the only step when you're debugging real API traffic. A few tools that pair naturally with it:
- If an API response or request body contains Base64-encoded data (common for images, tokens, or binary payloads embedded in JSON), Kravoy's Base64 Encoder/Decoder decodes it back to readable form without leaving your browser.
- If you need to actually make the API call that produced the JSON you're debugging — testing headers, methods, or auth — the API Request Tester lets you send a request and inspect the raw response, which you can then paste straight into the JSON Formatter.
Together, these cover the most common loop when working with an API: send a request, get back JSON, format it to actually read it, and decode any encoded values inside it.