Minify JSON to one line: what changes, what it saves and when to skip it

Minifying removes the whitespace between JSON tokens. RFC 8259 allows four whitespace characters between tokens: space, tab, line feed and carriage return. Minifying takes out the indentation, the line breaks and the space after each colon. Keys, values and key order stay exactly as they were, and whitespace inside a string stays too, since it's part of the value. The formatted sample comes first, then the Minify output.

{
  "order": {
    "id": "A-1042",
    "customer": {
      "name": "Ada Lovelace",
      "email": "ada@example.com"
    },
    "items": [
      {
        "sku": "KB-01",
        "qty": 2,
        "price": 49.9
      },
      {
        "sku": "MS-07",
        "qty": 1,
        "price": 19.5
      }
    ],
    "paid": true,
    "note": null
  }
}

{"order":{"id":"A-1042","customer":{"name":"Ada Lovelace","email":"ada@example.com"},"items":[{"sku":"KB-01","qty":2,"price":49.9},{"sku":"MS-07","qty":1,"price":19.5}],"paid":true,"note":null}}

The formatted sample is 346 bytes and the minified one is 194 bytes. That's 152 bytes less, or 44% of the formatted text. It's one small sample, so treat the percentage as an example, not a rule. Deeper nesting means more indentation on each line, and short values make that indentation a bigger share of the file. A document made mostly of long strings saves little, since minifying leaves string contents alone.

Browsers and servers negotiate compression with the Accept-Encoding and Content-Encoding headers, and MDN recommends it for every file except ones that are already compressed, like images, audio and video. gzip is the most common method, and br is the other one that matters. Repeated indentation compresses well. With gzip on, the gap between the formatted and minified text shrinks a lot. Your payloads will differ, so check the Content-Encoding header on a real response and measure both versions before you decide whether minifying is worth the work.

Logs are the clearest case for one record per line. JSON Lines puts one JSON value on each line, and the format's site says: "It's a great format for log files." A minified record can't hold a raw line break. RFC 8259 requires control characters to be escaped inside strings, so a line break inside a value is written as the two characters \n, and minifying removes the breaks between tokens. Each record fits on one line, so grep, tail and wc -l see whole records.

Any value that has to sit on one line, like an environment variable, is a good place for minified JSON, since a single line has no room for indentation.

Minifying needs valid JSON. A trailing comma, a single quote or a comment (unless Allow comments is on) makes the tool show an error instead of any output, so use the parse errors guide to find the mistake. Numbers come through untouched too. 1.10 stays 1.10, and a 16-digit ID like 9007199254740993 comes out exactly as written, because the tool reads each number by its written digits. The large numbers page explains why that matters for IDs.