JSON Builder — Create JSON Online

Create JSON online without typing a single brace

Writing JSON by hand is mostly punctuation work. The data — an order id, a customer city, two line items — takes seconds to think of; the braces, brackets, quotes and commas around it are what actually go wrong, especially once a document is nested three levels deep and a trailing comma hides at the bottom of a block. This JSON builder inverts the job: you describe the fields you want, and the tool writes the syntax.

Each row is three things — a path, a type, and a value. The path says where the value belongs in the document, the type says how it should be written, and the value is your data. The right-hand pane re-serializes the whole document on every keystroke, so the JSON you see is always the JSON you would get from a real parser round-trip. Because it is produced by JSON.stringify rather than string concatenation, it is valid by construction: balanced brackets, correctly escaped strings, and no trailing comma anywhere.

That makes the builder a good fit for the jobs where JSON is a means, not an end. Mocking an API response before the backend exists, hand-building a fixture for a test, filling in a config file whose shape you know but whose syntax you'd rather not fight, drafting a webhook payload to paste into a request, or assembling a small seed file for a database. When you're done, copy the result, or download it as a .json file and drop it straight into your project.

Already have a document and just need it tidied or checked? Use the JSON Formatter to reindent existing JSON, the JSON Validator to find the exact line an error sits on, or the JSON Viewer to explore a large payload as a collapsible tree.

Path syntax: dots nest, brackets make arrays

The path is the only syntax you have to learn, and it is the same dot-and-bracket notation you already use to read JSON in JavaScript, Python or a jq filter. A bare name is a top-level key. A dot creates (or reuses) an object one level down. A number in brackets addresses a position in an array, and an empty pair of brackets appends to the end of one. Containers are created on demand as the path is walked, so you never declare a parent object before writing into it.

Rows are applied in order, top to bottom, which gives you two useful properties. Sibling rows sharing a prefix merge into the same parent — customer.name and customer.email land in one customer object rather than overwriting each other — and key order in the output follows the order in which each key was first written, so the document reads the way you built it. If two rows target the identical path, the later one wins.

From rows to JSON: a worked order object

The sample loaded by the Load sample button builds a small e-commerce order: a couple of top-level fields, a customer with a nested address, and a two-item array of line items. Eight rows describe it completely, and the builder assembles them into the document below — note that qty is a number (unquoted) while sku is a string, and that the two items[0] rows merged into one object rather than creating two.

This is the whole model: no schema to define up front, no template to fill in, and nothing to re-indent afterwards. Delete a row and the key disappears; change a type and the value is rewritten in place. Toggle Minify when you want the single-line form for an environment variable or a curl body, and leave it off for the 2-space indentation most projects and code reviews expect.

orderId               string    ORD-10428
paid                  boolean   true
customer.name         string    Ada Lovelace
customer.address.city string    London
items[0].sku          string    TS-BLK-M
items[0].qty          number    2
items[1].sku          string    MUG-01
items[1].qty          number    1

{
  "orderId": "ORD-10428",
  "paid": true,
  "customer": {
    "name": "Ada Lovelace",
    "address": {
      "city": "London"
    }
  },
  "items": [
    {
      "sku": "TS-BLK-M",
      "qty": 2
    },
    {
      "sku": "MUG-01",
      "qty": 1
    }
  ]
}

Types: the part hand-written JSON gets wrong

JSON has six value types, and picking the wrong one is the most common data bug in a document that parses perfectly. The builder exposes all of them: String for text, Number for numeric values, Boolean for true/false, Null for an explicitly empty value, and JSON for a raw snippet — an array, a nested object, or anything else you want inserted verbatim after being parsed.

Two distinctions are worth internalising. First, quoted versus unquoted numbers: "42" and 42 are different values, and a schema validator, a strongly-typed client or a database import will treat them differently even though both look fine to a human. Second, null versus absent: a null field exists and says "we know this and it is empty", while omitting the row entirely says "no value was provided". APIs frequently distinguish the two — a PATCH with "nickname": null clears the nickname, whereas leaving nickname out leaves it untouched.

Booleans are worth a moment too. The string "false" is truthy in most languages; the boolean false is not. Choosing Boolean writes an unquoted literal, which is what feature flags, paid/unpaid markers and enabled switches need. If a row's value can't be read as the type you chose — letters in a number field, an unparseable JSON snippet — the row shows the problem inline and is left out of the output until it is fixed, so one bad field never breaks the rest of the document.