Lesson 12

Indentation and Line Breaks

When pretty-printing helps humans, when minified bytes matter, and team conventions.

JSON does not require whitespace between tokens. Indentation and line breaks are editorial choices—they do not change parsed values, but they change how humans and diff tools perceive the document.

Two representations, same data

Compact:

{"user":{"name":"Ada","roles":["admin","editor"]}}

Indented (2 spaces):

{
  "user": {
    "name": "Ada",
    "roles": ["admin", "editor"]
  }
}

Parsers treat them as equivalent; reviewers prefer the second in pull requests.

Team conventions

Common standards:

  • 2 spaces — default in many JavaScript and web projects
  • 4 spaces — some enterprise style guides
  • Tab — rare in JSON because many linters expect spaces

Pick one width per repository and enforce it in CI with a formatter check.

When to stay compact

  • Production HTTP bodies where bandwidth is tracked
  • Embedded configs with strict size caps
  • Machine-to-machine paths with no human reader

Store compact on the wire; pretty-print in logs or debug builds if needed.

Diff-friendly layout

Stable key ordering plus consistent indentation makes regressions visible in code review. Random key order or mixed spacing creates noisy diffs that hide real logic changes.

Treat layout as communication for humans, not as part of the JSON data model.

When you want to practice, use the related DevCove tool — optional, not part of this lesson.

Open related tool

Back to course overview