How do you make JSON.stringify() produce indented, human-readable output, and what is the middle argument doing in a call like JSON.stringify(value, null, 2)?

## The signature is the whole answer `JSON.stringify` accepts up to three arguments: ```js JSON.stringify(value, replacer, space) ``` The first is the value to serialize. The second is the **replacer** slot — a hook for filtering or transforming what gets written. The third is **space**, which controls indentation. Because JavaScript has positional arguments, you cannot skip the middle one: to reach `space` you must pass *something* for `replacer`. The idiom is `null`, which means "no replacer, serialize normally". Passing `undefined` works identically; `null` is simply the convention people recognise on sight. ```js JSON.stringify(obj, null, 2); // pretty, two-space indent ``` ## What space accepts **A number.** The value is truncated to an integer and clamped to a maximum of 10; the engine then indents each nesting level by that many spaces. A value of 0 or less — or a fractional value below 1 — means no indentation at all, identical to omitting the argument. ```js JSON.stringify(o, null, 2); // two spaces per level JSON.stringify(o, null, 20); // 10 spaces — clamped, not 20 JSON.stringify(o, null, 0); // compact, same as omitting space ``` **A string.** The string is used literally as the indent unit, and only its first 10 characters are taken. `'\t'` is the common choice for tab-indented files; a string of dots or vertical bars also works, which is occasionally handy when eyeballing deep structures. ```js JSON.stringify(o, null, '\t'); JSON.stringify(o, null, '....'); ``` **Anything else** is ignored, and you get compact output. (`Number` and `String` wrapper objects are unwrapped first and behave like their primitives; every other value simply has no effect.) ## What changes in the output With no `space`, the output contains no whitespace whatsoever — not even after the colons or commas: ```js JSON.stringify({ name: 'svc', ports: [80, 443] }); // {"name":"svc","ports":[80,443]} ``` With a non-empty `space`, three things change: every property and array element goes on its own line, each nesting level is prefixed by the indent unit repeated once per level, and the separator between a key and its value becomes `": "` rather than `":"`. Empty objects and arrays stay collapsed as `{}` and `[]` — there is nothing inside to put on a line. ```js JSON.stringify({ name: 'svc', ports: [80, 443] }, null, 2); // { // "name": "svc", // "ports": [ // 80, // 443 // ] // } ``` Note also that `space` does not add a trailing newline. If you are writing a config file that a linter expects to end with one, you append it yourself. ## Indentation is not part of the data Whitespace between JSON tokens is insignificant, and `JSON.parse` skips it. Pretty-printed text and compact text describing the same data parse to values that are indistinguishable — the indentation exists purely for a human reader. Only space, tab, carriage return and line feed count as JSON whitespace, which is exactly what `space` produces. ## When to use which Use indentation where a person or a diff will read the text: files checked into a repository (`package.json`-style configuration), snapshot fixtures in tests, a debugging dump, a CLI that prints a result to a terminal. Indented output makes line-based diffs meaningful, which is a real reason to store configuration pretty-printed. Use compact output where a machine will read it: request and response bodies, cache entries, message payloads, high-volume log lines. Indentation is pure overhead there — every level of nesting multiplies the bytes spent on spaces, and for a large deeply-nested document that is a noticeable fraction of the payload. A practical middle ground for logging: keep the stored representation compact and pretty-print only at the moment a human asks to see it, so you are not paying for whitespace on every write. ## The common mistakes The two that come up in interviews are passing the indent as the **second** argument — `JSON.stringify(obj, 2)`, where `2` lands in the replacer slot, is ignored as a replacer, and produces compact output — and assuming a large number gives deeper indentation when the value is clamped to 10.