JSON Formatting Best Practices for Developers

JSON is everywhere — APIs, config files, data exchange. A few conventions make it far easier to read, review and maintain. Here are the practices worth adopting.

Pretty-print for humans, minify for machines

• Pretty-printed (2-space indent) JSON is for files people read and edit: config, fixtures, documentation.
• Minified JSON (no whitespace) is for transport — API responses and storage — where every byte counts.

Keep your source files pretty-printed and let your build/serialization minify on the way out.

Be consistent with indentation

Pick 2 spaces (the most common) and stick to it across the project. Consistent indentation makes nesting obvious and keeps diffs clean.

Sort keys for clean diffs

Alphabetizing object keys means a changed value produces a one-line diff instead of a reshuffle. It's especially valuable for config files in version control. Our JSON formatter has a one-click "Sort keys" for this.

Naming conventions

• Pick one key style — camelCase (common in JS/web APIs) or snake_case — and use it everywhere.
• Use clear, consistent names; prefer createdAt over ts.
• Represent dates as ISO 8601 strings ("2026-06-25T10:00:00Z") for unambiguous parsing.

Structure tips

• Use arrays for lists of like items, objects for fixed sets of fields.
• Avoid deeply nested structures when a flatter shape works — they're harder to read and query.
• Use null deliberately to mean "no value", not empty strings.

Validate before you ship

A malformed config or payload can crash an app at the worst moment. Validate JSON as part of your workflow — paste it into the formatter to confirm it parses and to see the structure as a tree. Because it runs locally, you can safely check payloads containing tokens or customer data without uploading them anywhere.

FAQ