JSON formatter and validator

What JSON is, in plain words

JSON, short for JavaScript Object Notation, is a way of writing down structured information as plain text so that different programs can exchange it. It is how most apps and servers talk to each other. When an app asks a server for a list of products, the answer typically arrives as JSON: a block of text with names and values, arranged in curly and square brackets.

It is designed to be readable by both machines and people, but only up to a point. A server will usually send it as one long line with no spaces, which is efficient for the machine and awful for a human. A formatter takes that line and lays it out with indentation so that you can see its structure.

This tool does that, and also checks that the text is valid JSON, which is the other half of its usefulness. If a comma is missing or a bracket is unclosed, it tells you where.

How to use the tool

1. Paste your JSON into the left box, or edit the example.
2. Press Format to see it laid out with indentation, or Minify to squash it into one compact line.
3. If it is invalid, the right-hand box tells you what is wrong and the line and column where it was found.
4. Use Copy to take the result with you.

The indent selector switches between two and four spaces. Most projects use two. Nothing you paste is sent anywhere: the work is done in your browser, and the text stays on your device.

The mistakes that break JSON most often

A trailing comma after the last item in a list or object is the most common error. JavaScript itself may tolerate it in some places, but JSON does not. Remove the final comma.

Single quotes are another. JSON requires double quotes around names and text values. Single quotes look similar and are invalid.

Unquoted keys, such as name: 'Sachin' instead of "name": "Sachin", are valid in some programming languages and not in JSON. Comments are also not allowed, so a line starting with // or text inside /* */ will cause an error.

Finally, watch for unclosed brackets and braces, especially in long documents. The error location the tool reports is where the parser noticed the problem, which can be slightly after the actual mistake, so look just before it.

Why a non-programmer might need this

If you commission software, you will sometimes be handed JSON: a sample response from an API, a configuration file, an export of your data. Being able to open it and see its shape helps you understand what a system is actually sending and receiving, and to ask better questions.

It is also useful for checking what a vendor has given you. If you ask for an export of your customer data and receive a single unreadable line, running it through a formatter shows whether it is complete and structured sensibly.

Seeing the data is a useful form of due diligence. It is hard to hide a gap in a document you can read.

Why it runs in your browser, and why that matters

Many online formatters send your text to a server to process it. That is fine for a harmless sample and a poor idea for anything containing real customer data, keys or internal details. JSON pasted into such tools has leaked more than once.

This tool runs entirely in your own browser. The text is parsed and formatted by code on your device. You can check this yourself: switch off your connection after the page has loaded and it will keep working.

The same principle applies to many small utilities. If a task can be done on the user's side of the line, it usually should be.

A few habits that help when working with JSON

• Format before you read. Structure is easier to see than to imagine.
• Keep a small, clean example of each data shape your product uses. It is the best documentation a new developer can have.
• When something breaks, check the JSON first. A surprising share of bugs are a missing field or an unexpected value.
• Do not paste real customer data into tools you do not trust.
• Validate before you send. A malformed request fails in ways that are slow to diagnose.

These are small things, and together they save hours over the life of a project.

Reading the structure: objects, arrays and values

Once formatted, JSON has only a few shapes to recognise. An object is a set of named values written inside curly braces, like a record with labelled fields: a name, a price, a category. An array is an ordered list written inside square brackets: a list of products, or a list of numbers. A value can be text in double quotes, a number, true or false, null for nothing, or another object or array nested inside.

Most real documents are objects containing arrays of objects. A response listing products is an object with a field called products, whose value is an array, each item of which is an object describing one product. Reading it is a matter of following the indentation down. The formatter does the first half of that work for you.

When you are checking an export or a sample from a vendor, look at three things: whether each field you expect is present, whether the types look right, such as numbers that are not in quotes, and whether there is anything surprising, such as empty values where there should be data.

Big files and the limits of a browser tool

This tool is designed for the everyday case: a response, a configuration, a sample of a few kilobytes up to a few megabytes. Very large files, of tens of megabytes, can strain a browser tab, and it is better to process them with a command-line tool or a script. If the page becomes sluggish, that is a sign you have reached that limit.

For large exports, a developer can write a short script to check structure and sample the content. If you are routinely handling such files, ask whether the system that produces them could offer a smaller summary or paged output instead.

Related formats you may meet

JSON is not the only way data is exchanged. CSV, rows and columns of text separated by commas, is common for spreadsheets and exports. XML is an older, more verbose format still used in some government and banking systems. YAML is a human-friendly format often used for configuration files.

Sometimes you will meet a file with one JSON document per line, usually called JSON Lines. It is not a single valid JSON document, so a formatter will complain about it. Each line is valid on its own. Paste a single line at a time if you want to inspect it.

When you need more than a formatter

A formatter shows structure. It does not tell you whether the content is right. For that you need a schema: a description of what fields a document should have and what type each one is. A developer can use a schema to validate every message automatically, which catches whole classes of errors before they reach a customer.

If you are building something with an API, ask whether there is a schema and where it is kept. A product with a clear, current schema is a product that others can integrate with, and that you can hand to a new team without a long explanation.