JSON Formatter
JSON Formatter re-indents a JSON document to 2 spaces, 4 spaces or tabs, optionally sorts object keys alphabetically, and strips JSONC comments — without changing a single value. Parsing, formatting and serialization all run in your browser, so the payload never leaves the page.
- Input size
- 0 B
- Formatted size
- 0 B
- Lines
- 0 → 0
- Input indent
- Compact
The formatted JSON appears here.How does JSON formatting work?
JavaScript Object Notation (JSON) is specified internationally by RFC 8259, ECMA-404, and ISO/IEC 21778:2017. As a language-independent text interchange format, JSON has supplanted XML, YAML, and custom binary formats across modern web APIs, microservice RPCs, and NoSQL document stores. While JSON is syntactically simple, formatting and normalizing arbitrary JSON documents requires deep consideration of whitespace semantics, character encodings, object key ordering, comment conventions, and syntactical sanitization.
Whitespace Grammar in RFC 8259
In RFC 8259 Section 2, the JSON lexical specification defines exactly four allowable whitespace characters that may exist before or after any structural token ([, {,], }, :, and ,):
- Space (ASCII 0x20)
- Horizontal Tab (ASCII 0x09)
- Line Feed (ASCII 0x0A)
- Carriage Return (ASCII 0x0D)
No other Unicode whitespace characters—such as Non-Breaking Space (\u00A0), Zero-Width Space (\u200B), or Em Space (\u2003)—are permitted outside of quoted string literals. When a document contains illegal Unicode whitespace between structural tokens, standard parsers immediately throw fatal syntax exceptions. Formatting JSON involves parsing the raw token stream, stripping extraneous whitespace, and re-synthesizing indentation according to precise nesting depth rules.
Indentation Strategies: 2 Spaces, 4 Spaces, vs. Tabs
The choice of indentation profoundly affects file readability and line wrapping in code review tools. The three dominant formatting standards serve different development paradigms:
The modern standard across JavaScript, TypeScript, Node.js, and React. Conserves horizontal real estate in deeply nested JSON structures, preventing excessive line wrapping on laptop displays and terminal splits.
Prevalent in Python, Java, C#, and Go backend ecosystems. Provides clear visual hierarchy for shallow to moderately nested structures, making structural block boundaries immediately obvious.
The accessibility champion. Storing literal tab characters allows each developer to adjust their display width (2, 4, or 8 columns) without modifying the underlying bytes in version control.
Object Key Ordering: Lexicographical vs. Natural Sorting
RFC 8259 Section 4 explicitly dictates that JSON objects consist of unordered collections of zero or more name/value pairs. Consequently, JSON parsers do not guarantee key order preservation. However, in version control diffs (e.g. Git) and human data audits, fluctuating key order causes massive false diffs. Sorting object keys restores deterministic canonical serialization:
- Alphabetical (A-Z) Sort: Uses standard Unicode code point comparison. Fast and deterministic, but causes numbers in keys to sort counterintuitively (e.g.,
"item1","item10","item2"). - Natural Sort: Evaluates numeric chunks inside key strings as numbers rather than ASCII characters. Produces intuitive human ordering (e.g.,
"step1","step2","step10").
Handling Unicode: Escaping vs. Native Characters
All JSON text MUST be encoded using Unicode, with UTF-8 as the mandatory default according to RFC 8259 Section 8.1. Within string literals, any character may be represented directly as UTF-8 or escaped via six-character sequences beginning with \u followed by four hexadecimal digits (e.g. \u00A9 for ©).
Escaping non-ASCII characters guarantees that payloads can survive transmission through legacy systems that corrupt high-order UTF-8 bytes. Conversely, unescaping these sequences into native UTF-8 characters drastically improves human readability in multilingual payloads and saves up to 50% of file size in non-Latin scripts (Arabic, Cyrillic, Chinese, Japanese, Hebrew).
Which keyboard shortcuts does the JSON formatter support?
Frequently asked questions
What is the difference between alphabetical sort and natural key sort?
Standard alphabetical (lexicographical) sorting compares character code points sequentially. Under alphabetical sort, 'key10' precedes 'key2' because the character '1' has a lower ASCII code point than '2'. Natural key sorting recognizes embedded numeric sequences and sorts them numerically, so 'key1', 'key2', and 'key10' appear in expected human order.
Why does RFC 8259 prohibit comments in standard JSON?
Douglas Crockford deliberately removed comments from standard JSON around 2001 to prevent developers from using comments to hold parsing directives or metadata, which famously caused interoperability failures in early HTML and XML ecosystems. Modern configuration formats like JSONC (JSON with Comments) allow '//' and '/* */', but standard REST APIs and parsers strictly reject them. The ToolsByUs formatter automatically strips comments while preserving strings.
When should I escape Unicode characters to \uXXXX sequences?
Escaping non-ASCII characters to \uXXXX escape sequences is essential when transmitting JSON across legacy transport channels, 7-bit ASCII protocols, or systems that lack reliable UTF-8 locale configurations. In contrast, unescaping \uXXXX back to native UTF-8 characters reduces payload size and enhances readability for human editors.
Should I indent with 2 spaces, 4 spaces, or tabs?
Two spaces is the de facto standard in JavaScript, TypeScript, and modern web APIs, balancing readability with horizontal space conservation. Four spaces is common in Python, Java, and C++ ecosystems. Tabs provide true user-side accessibility, allowing each developer to configure their editor's tab width visually without altering file byte counts.
Does this formatter store or log my formatted JSON data?
Never. All formatting, key sorting, unicode conversions, and comment removals occur exclusively in client-side memory inside your web browser. Zero network calls or API requests are dispatched.
Does formatting change my numbers or lose precision?
Large integers can lose precision. JavaScript parses JSON numbers as IEEE-754 doubles, so an identifier beyond 2^53 — a snowflake ID, for example — is rounded to the nearest representable value by any JavaScript-based formatter, this one included. If a payload carries identifiers that long, keep them as strings in the source data; that is the only fix that survives every parser rather than just one.