How to Format JSON Online

Formatting JSON makes it easier to read or more compact to send and store. A formatter can add indentation, remove unnecessary whitespace, and help reveal syntax errors—but sorting keys or processing numbers can have effects beyond appearance. Use the steps and checks below to format JSON without accidentally changing what your application needs.

Pretty-printing and minifying

Pretty-printing adds line breaks and indentation so you can scan nested objects and arrays. It is useful when reviewing a response, editing a configuration file, or comparing data with a person. For example, this compact JSON:

{"name":"Mina","active":true,"tags":["editor","admin"]}

can be pretty-printed as:

{
  "name": "Mina",
  "active": true,
  "tags": [
    "editor",
    "admin"
  ]
}

Minifying removes optional whitespace, usually putting the document on one line. This can reduce the number of characters in a file, but it does not compress the data in the same way as a compression format such as gzip. Minified JSON is harder to inspect manually, so keep a readable copy when you need to edit or troubleshoot it.

For ordinary JSON with unique object keys and values that your parser can represent, pretty-printing and minifying change whitespace rather than the underlying data. However, a formatter must parse and serialize the document, and implementations can differ in how they handle duplicate keys, number precision, or escaping. Treat the formatted output as a new file and check it before replacing an important original.

Format JSON online

1. Open the TIG JSON Formatter.
2. Paste or enter the JSON you want to format.
3. Choose an indentation (2 spaces, 4 spaces or tabs) for readable output, or Minify for a compact version.
4. Review the result, then copy it or save it to your project.
5. If the input is rejected, the formatter reports the first error with its line and column; the JSON Validator also shows the line with a marker under the problem.

A formatter can help make valid JSON readable, but it cannot infer what the data is supposed to mean. After formatting, check important fields and test the result with the application that will consume it.

Choose an indentation style

Indentation is a readability choice; JSON does not require a particular number of spaces. Two spaces per level is a common style for compact, readable files. Four spaces can make nesting easier to follow on a wide screen, while tabs may fit a project that already uses tabs. Pick one convention and use it consistently.

Indentation changes whitespace, not the data structure. It does increase the file’s character count, so minifying can be useful when a compact representation is needed. Avoid inserting spaces or line breaks inside a quoted string: those characters are part of the string value, not formatting whitespace.

Should you sort object keys?

JSON objects are collections of name-value pairs, and object member order is not a dependable way to express meaning. Arrays, in contrast, are ordered: changing the order of array items changes their meaning whenever the application uses that order. Sorting keys can make files easier to compare or keep generated output consistent, but it is optional and can make a file differ from the original.

Sort keys only when there is a practical reason, such as creating readable diffs or following a project convention. The TIG formatter’s “Sort keys A–Z” option sorts keys in every object at every level and keeps array order; inspect the output before using it. Note that formatters built on JavaScript, including this one, place keys that look like whole numbers ("1", "20") before other keys even when sorting is off. Do not sort array contents as if they were object keys.

Also be cautious with duplicate object names. RFC 8259 says object names should be unique; when they are not, different parsers may handle them differently. Sorting or reserializing such an object can obscure the issue or discard a value. Validate the input and resolve duplicate names at the source rather than relying on formatting to decide which value should survive.

If JSON is used for a signature, cache key, or exact text comparison, changing key order or number spelling may change the bytes even when the data appears equivalent. Follow the system’s required canonicalization procedure instead of assuming that alphabetically sorting keys is sufficient.

Example: format an API response

Suppose an API returns this one-line response:

{"order":{"id":"A-1042","items":[{"sku":"MUG-BLUE","quantity":2},{"sku":"NOTEBOOK","quantity":1}],"paid":true}}

Pretty-printing makes the order and its two line items easier to inspect. You can check that paid is a Boolean, quantity values are numbers, and the order ID is a string. The formatting should not reorder the items array: its order may matter to the application or to the person reading it. If you later minify the response for storage or transfer, compare the values—not just the one-line appearance—to confirm nothing important changed.

Working with large JSON files

Large files take more time and memory to load, parse, and display. A browser may become slow or unresponsive if the input is too large for the available memory. If a file is unwieldy, consider whether you can process a smaller sample, split the data at meaningful record boundaries, or use a command-line or streaming tool designed for large inputs. Do not split text at arbitrary character positions: that can cut through a string or leave an incomplete object and produce invalid JSON.

Before pasting sensitive data into any online tool, check that the tool and your organization’s data-handling rules are appropriate for it. The TIG JSON Formatter runs in your browser and does not send the text to a server. For a large or valuable file, keep an unchanged backup. Test the formatter with a small representative section first, and verify that the full result is valid before saving it over the original.

Numbers larger than 2^53

JSON’s number syntax allows decimal numbers, but it does not require every parser to store them with unlimited precision. Many browser-based tools and JavaScript applications use the JavaScript Number type, which cannot represent every integer exactly beyond the safe-integer range. The largest safe integer is 9007199254740991 (2^53 − 1). For example, 9007199254740993 may be parsed as 9007199254740992 in JavaScript; once rounded during parsing, a formatter cannot recover the original value.

This matters for large database IDs, account numbers, and exact financial values. If the receiving system permits it, represent an exact large integer as a JSON string:

{
  "accountId": "9007199254740993"
}

A string preserves the digits, but it is a different JSON type from a number. Confirm that the software consuming the JSON expects a string. For decimal amounts, use a representation and decimal-handling approach agreed with the application rather than assuming a formatter will preserve arbitrary precision.

If exact numeric values are important, test the round trip: parse the original, format it, then inspect the output and compare the critical values. Do not rely on visual similarity alone; rounded numbers can look plausible while being wrong.

Summary

• Pretty-print JSON to make nested data easier to read; minify it when compact output is useful.
• Choose a consistent indentation style; whitespace inside strings is data, not formatting.
• Sort object keys only when useful, and never treat arrays as unordered.
• Large files can strain browser memory; preserve a backup and validate the output.
• Store integers beyond JavaScript’s exact range as strings when the receiving system supports that representation.