Free · Fast · Privacy-first

Format JSON with Indentation

Different projects use different indentation standards.

⚡

Choose 2-space, 4-space, or tab indent

🔒

Matches your project style guide

✨

Instant browser-based formatting

⚡

Copy output in one click

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this JSON Formatter to your website

Drop the JSON Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/json-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

The 2-Space vs 4-Space Debate, and What the JSON Spec Actually Requires

The JSON specification in RFC 8259 requires nothing about indentation. It defines whitespace as any sequence of space (0x20), tab (0x09), line feed (0x0A), or carriage return (0x0D) characters placed at positions surrounding the structural characters in the grammar. The choice of 2 spaces, 4 spaces, or a tab is entirely a human convention with no impact on the data. JavaScript projects following the Airbnb or Google JavaScript style guides use 2 spaces. Python projects following PEP 8 traditionally use 4 spaces. The json.dumps() function in Python accepts any positive integer as the indent parameter, and json.dumps(data, indent=4) is the form used in most Python tutorials and documentation examples.

Tabs versus spaces is a separate question. In JSON config files tracked in version control, tabs have the advantage that each developer can configure their editor to display them at their preferred visual width (2, 4, or 8 characters) without modifying the file itself. Spaces are explicit and self-contained: a 2-space indented JSON file looks like 2-space indented JSON to every reader regardless of their editor settings. The .editorconfig specification lets teams declare the indentation standard for each file type. A setting of indent_style = space and indent_size = 2 for all *.json files enforces 2-space JSON across every editor and CI system that respects the .editorconfig format.

Converting between indent styles is a routine task in mixed-team or multi-vendor projects. A project may receive JSON config files from a vendor formatted with 4 spaces while the internal standard is 2 spaces. A team migrating from a Python backend to a Node.js backend may need to convert configuration files from the Python 4-space convention to the JavaScript 2-space convention. FixTools handles this by parsing the input JSON first, which discards all existing whitespace completely, and then re-serialising the parsed data with the chosen indent. This converts any input indentation style to any output style in a single step, without needing a text editor macro, a regular expression, or a sed command.

Indent settings also intersect with JSON5 and JSONC variants in ways worth knowing. JSONC is the lightly extended JSON used by VS Code in tsconfig.json, settings.json, and launch.json files, allowing // and /* */ comments but preserving the rest of the JSON grammar. JSON5 is a fuller superset that adds unquoted keys, single-quoted strings, trailing commas, hex numbers, and NaN. Both communities have their own indentation conventions: JSONC follows whatever the host project uses (2 spaces in most VS Code defaults), while JSON5 files frequently use 2-space indentation matching their JavaScript-flavored grammar. FixTools targets strict JSON output, so if you paste JSON5 or JSONC, comments and trailing commas will be flagged as errors. Strip them first with a JSONC-aware preprocessor or accept the conversion to strict JSON as part of the normalisation step.

For very large config files where indentation choice meaningfully affects file size, the calculus shifts. A 5MB minified JSON config grows to roughly 7MB at 2 spaces and 9MB at 4 spaces. Most version control systems handle either size fine, but very large pull requests sometimes hit GitHub's diff rendering limit and show the file as binary, which makes review impossible. For files in that range, prefer 2-space indentation or split the config into multiple smaller files keyed by domain. Some teams adopt a hybrid approach: store the canonical form with 2-space indentation in the repository and provide a build step that emits a minified version for production deployment. This keeps human-readable diffs for code review while keeping the deployed artifact compact for runtime.

Indentation choice also affects tooling beyond Git and editors. JSON Schema validators, OpenAPI generators, and contract testing tools all read JSON files regardless of indent, but their error messages reference line and column numbers that depend on the formatting. A 4-space indented config gives more vertical breathing room for error reports to point at specific keys, while a 2-space indented config keeps the file shorter and faster to scan visually. CI logs often truncate at fixed line widths, so deeply nested 4-space JSON may overflow the log column and become unreadable in CI failure output. Picking an indent and committing to it across the team keeps these downstream tools consistent and prevents the noise that comes from each developer reformatting on save.

RFC 8259 Section 2, Insignificant Whitespace Python json.dumps indent documentation EditorConfig specification

How to use this tool

💡

Paste your JSON, select your preferred indentation size, then click Format.

How It Works

Step-by-step guide to format json with indentation:

1
Paste your JSON
Paste the JSON you want to indent into the input area. The formatter accepts JSON in any current state, including fully minified single-line input, already-indented JSON that needs a different indent size, and JSON with mixed or inconsistent whitespace from manual editing.
2
Choose indentation size
Select 2 spaces, 4 spaces, or tabs from the indentation options panel. Two spaces is the default and the most common setting for JavaScript and TypeScript. Four spaces matches Python PEP 8 conventions. Tabs allow each developer to configure their own display width in their editor.
3
Format and copy
Click Format. FixTools parses the JSON, discards all existing whitespace, and re-serialises it with your chosen indentation. Copy the normalised output and paste it into your project file, documentation, or version-controlled config.

Real-world examples

Common situations where this approach makes a real difference:

Full-stack developer

A developer migrating a project from a Python backend to a Node.js backend needs to reformat several JSON config files from the Python 4-space convention to the JavaScript 2-space convention used by the new codebase. Pasting each file into FixTools, selecting 2 spaces, and copying the output converts all config files to the new standard in a few minutes without writing a conversion script or using find-and-replace, which would struggle with nested indentation.

Open source maintainer

A maintainer receives a pull request that includes a package.json file formatted with tabs while the rest of the project uses 2-space indentation. They paste the submitted file into FixTools, select 2 spaces, and include the reformatted output in their review comment showing the contributor the expected format. The clear before-and-after comparison helps the contributor understand the project standard and make the correction quickly.

Configuration manager

An infrastructure engineer manages dozens of JSON config files for cloud services from multiple vendors. Different vendors export configurations with different indentation styles. Using FixTools to normalise all configs to a single 4-space indentation standard before committing them to the infrastructure repository makes git diffs clean and prevents the confusion of seeing mixed styles in the same codebase review.

Technical educator

An online course instructor writes JSON examples for students learning API integration. The course platform renders code blocks with fixed-width fonts where 4-space indentation makes nesting levels more visually distinct for learners who are new to nested data structures. FixTools lets the instructor quickly reformat all example JSON to 4-space indentation before publishing each lesson module, ensuring all examples are consistent and easy to follow.

Pro tips

Get better results with these expert suggestions:

Set JSON indentation in .editorconfig

Add a [*.json] section to your project's .editorconfig file with indent_style = space and indent_size = 2 (or 4 for Python-style projects). Most modern editors including VS Code, IntelliJ IDEA, and Vim with the EditorConfig plugin respect this setting and apply it automatically when editing JSON files. CI formatters like Prettier also read .editorconfig, so the setting is enforced consistently across local development and automated pipelines.

Python json.dumps indent=None vs indent=0

In Python, json.dumps(data, indent=None) produces minified single-line output with no whitespace between tokens. json.dumps(data, indent=0) produces each key-value pair on its own line with no indentation, which is useful for log lines that need to be parsed line by line. json.dumps(data, indent=2) produces the standard human-readable form. Understanding the difference prevents accidental selection of indent=0 when you actually want indented output.

Use tabs for user-configurable display width

If your JSON config files will be read by developers with different editor preferences, tab indentation lets each developer configure their tab display width in their editor without modifying the file. This makes the file neutral with respect to visual indentation width while still being consistently formatted. The trade-off is that some automated tools, including certain JSON Schema validators and diff viewers, render tabs differently than their configured width.

Normalise before git commit

If multiple developers edit the same JSON config file with different indentation settings, each save can produce a diff that changes every line. Adding Prettier as a pre-commit hook with the command prettier --write "**/*.json" normalises all JSON file indentation to the configured standard before each commit. This keeps the git history clean and ensures reviewers only see actual data changes, not reformatting noise.

FAQ

Frequently asked questions

The right size depends on your project ecosystem. JavaScript and TypeScript projects commonly use 2 spaces, following the Airbnb and Google JavaScript style guides. Python projects use 4 spaces by PEP 8 convention. Go projects use tabs because gofmt enforces tab indentation by default. Check your project's .editorconfig, .prettierrc, or eslint configuration file for the declared standard. Use the same setting in FixTools to produce output that matches your codebase without requiring a post-format adjustment.

No. JSON parsers ignore all whitespace between tokens as defined in RFC 8259. A document indented with 2 spaces, 4 spaces, tabs, or no indentation at all is parsed identically and produces the same in-memory data structure. The specification explicitly defines spaces, tabs, carriage returns, and line feeds as insignificant whitespace that has no effect on the meaning or validity of the document. Changing indentation never changes the data.

Yes. Paste the tab-indented JSON into FixTools, select 2 spaces, and click Format. FixTools parses the JSON first, which discards all existing whitespace regardless of whether it is tabs, spaces, or a mixture of both, and then re-serialises the data with 2-space indentation. The output is data-identical to the input but uses your chosen indent style consistently throughout every level of nesting.

Add an .editorconfig file to the project root with a [*.json] section specifying indent_style and indent_size. Use Prettier with a .prettierrc file containing your tab width and indent settings. Add Prettier as a pre-commit hook using lint-staged so that all JSON files are automatically normalised before they enter the repository. Run the same Prettier check in CI to catch any files that were committed without going through the hook.

json.dumps(data, indent=N) formats the Python dict or list as a JSON string with N space characters of indentation per nesting level, with each key-value pair on its own line. indent=None (the default) produces compact single-line output. indent=0 puts each element on a new line but with zero spaces of indentation. indent=2 is the most readable general-purpose format for display and documentation. indent=4 is preferred in many Python tutorials and follows the PEP 8 4-space convention.

Both are widely used. Two-space indentation dominates the JavaScript and TypeScript ecosystem, where npm's package.json files use 2 spaces by default and popular style guides recommend it. Four-space indentation is more common in Python and Java projects. There is no universal standard across all languages. The practical recommendation is to match the convention already established in your project rather than introducing a new one.

Yes, though they are unusual. JSON.stringify accepts any integer from 1 to 10 as the space argument. Python's json.dumps accepts any positive integer. Three-space indentation is valid but almost never used in practice. FixTools offers the three most common options: 2 spaces, 4 spaces, and tab. For other widths, use the browser console: JSON.stringify(JSON.parse(yourJson), null, 3) produces 3-space indented output.

When you reformat JSON in FixTools, the tool first parses the entire input into a JavaScript data structure using JSON.parse(). This step discards all existing whitespace because the parser treats it as insignificant. The data structure is then re-serialised from scratch using JSON.stringify() with your chosen indent setting. This means all existing indentation, extra blank lines, inconsistent spacing, and mismatched indent sizes in the input are completely replaced with uniform fresh indentation in the output.

Prettier reads .editorconfig as one input but its own .prettierrc takes precedence when both are present. If your .editorconfig says indent_size = 4 but a .prettierrc declares "tabWidth": 2, Prettier uses 2. Many teams hit this when adopting Prettier on top of an existing .editorconfig configuration without realising the override. The fix is to align the two files: set tabWidth and useTabs in .prettierrc to match the indent_size and indent_style in .editorconfig, or delete the conflicting setting from one of them. Run prettier --check on a sample file to confirm the result. CI failures from indentation drift almost always trace back to this precedence mismatch.

Indent size has a measurable but small effect on file size. A typical 100KB minified JSON config grows to roughly 140KB at 2 spaces and 180KB at 4 spaces because every nesting level adds bytes. For Git, the larger files mean slightly larger pack sizes and slightly slower diffs, but the readability gain almost always outweighs the cost. For runtime parsing, indent has no effect because parsers skip whitespace at the lexer stage. For network transmission, prefer minification combined with gzip or brotli which compress repeated whitespace to nearly nothing. The practical rule is: indent for humans reading the file, minify for machines parsing it at scale, and never commit minified config files.

Always commit indented JSON to version control. Minified JSON makes pull request diffs unreadable because every change touches the same single long line, and reviewers cannot tell what data actually changed. Indented JSON gives meaningful line-level diffs where each changed value sits on its own line and the surrounding context is clear. For generated minified JSON used in production builds, treat the minified file as a build artifact produced during deployment, not as a checked-in file. If the minified form must be committed for some downstream tool, also commit the indented source and add a build step that generates the minified version, with the relationship documented in the project README so future maintainers understand which file is the canonical source.