Minified vs Pretty JSON: When Minifying Matters

Search pages and dashboards often put a filter object in the URL so the view can be shared. JSON in a query parameter has to be percent-encoded: braces, quotes, colons and commas each become three characters, and so do spaces (%20) and newlines (%0A). Here is a typical filter:

{
  "status": [
    "paid",
    "shipped"
  ],
  "region": "EU",
  "minTotal": 50,
  "sort": {
    "field": "createdAt",
    "order": "desc"
  },
  "page": {
    "size": 25,
    "cursor": null
  }
}

• Pretty printed: 198 bytes, and 430 characters after encodeURIComponent.
• Minified: 134 bytes, and 238 characters after encoding.
• The 64 spaces and newlines alone add 192 characters to the URL.

The HTTP standard sets no URL length limit, but servers and proxies do. nginx, for example, rejects a request line longer than its header buffer, 8 KB by default, with a 414 error. A filter that grows with user input reaches that limit far sooner when it is pretty printed.

const query = new URLSearchParams({ filter: JSON.stringify(filter) });
const url = "/orders?" + query.toString();

RFC 6265 asks browsers to support cookies of at least 4096 bytes, including the name and attributes, and many stop at about that size. Cookie values also cannot contain double quotes, commas, semicolons, backslashes or spaces, so JSON is usually Base64 or URL encoded before it goes into a cookie.

Base64 adds a third. The same filter is 264 characters in Base64 when pretty printed, and 180 when minified. If a cookie holds user preferences that grow over time, minifying is the difference between fitting and silently losing the cookie.

Many log platforms bill by the volume they ingest. A sample structured log event measured 277 bytes pretty printed and 225 bytes minified, about 19 percent less. At a million events a day, that is 277 MB against 225 MB, every day.

The bigger problem is not size. Most log shippers treat each line as one event unless multi-line parsing is set up. The pretty-printed event spans 14 lines, so it arrives as 14 broken fragments that cannot be searched by field. Write one minified object per line, a format often called JSON Lines or NDJSON:

{"ts":"2026-10-18T09:15:02.481Z","level":"info","service":"checkout","traceId":"4bf92f3577b34da6a3ce929d0e0e4736","msg":"order paid","orderId":"ord_8f2k1","amount":129.9,"currency":"EUR","user":{"id":"u_5521","country":"DE"}}

Most logging libraries do this by default. The usual way it breaks is a developer passing an indent argument to JSON.stringify to make local output readable, and that setting reaching production.

localStorage holds strings only, and major browsers allow around 5 MB per origin. When it is full, setItem throws a QuotaExceededError, and an app that caches API responses there stops caching without warning unless it catches that error. Store the result of JSON.stringify(value) with no indent argument, and handle the failure:

try {
  localStorage.setItem("orders-cache", JSON.stringify(orders));
} catch (error) {
  if (error.name === "QuotaExceededError") localStorage.removeItem("orders-cache");
  else throw error;
}

A QR code holds at most 2,953 bytes, at its largest size with the lowest error correction. Long before that limit, every extra byte makes the code denser and harder to scan from a screen or a printed label. Tickets, boarding passes and device pairing codes that carry JSON should always carry it minified.

Message brokers have limits too. Kafka brokers reject messages larger than message.max.bytes, about 1 MB by default, and producers do not compress unless compression.type is set. A large event built with pretty printing hits that limit sooner than it needs to.

PostgreSQL has two JSON types. json stores the input text exactly, whitespace included. jsonb stores a parsed binary form and throws the whitespace away, so minifying before an insert into a jsonb column changes nothing. MySQL's JSON type also stores a binary form. JSON kept in a plain TEXT or VARCHAR column keeps every space, and those bytes are read on every query that touches the row.

• HTTP responses with gzip or Brotli enabled. The difference after compression is small, as the JSON Minifier page shows.
• jsonb and other binary JSON columns, which drop whitespace on insert.
• Config files and fixtures in a git repository. People read and review them, and the JSON Formatter keeps them readable.