# FracturedJson: a JSON formatter that keeps small objects on one line and aligns them like a table

> FracturedJson is a family of JSON and JSONC formatters that write objects and arrays inline when they are short and simple, align sibling fields into columns, and wrap long arrays several items per line. The .NET library, the fracjson command line tool and a browser formatter all live in one repository.

**j-brooke/FracturedJson** — JSON/JSONC formatter that stays compact: similar objects align like a table, short values stay inline.

- Repository: https://github.com/j-brooke/FracturedJson
- Stars: 916 · Forks: 15
- Language: C#
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/j-brooke-fracturedjson

## The rule is that short objects stay on one line, and that is what changes everything

FracturedJson is a family of utilities that format JSON data in a way that is easy for humans to read but fairly compact. Arrays and objects are written on single lines, as long as they are neither too long nor too complex. When several such lines are similar in structure, they are written with fields aligned like a table. Long arrays are written with multiple items per line across multiple lines. That is the entire design, and it is a departure from the usual pretty-printer. The conventional formatter expands every object onto multiple lines, which for a document with hundreds of small records turns into a wall of braces and colons where the eye has to work to find the boundaries of a record. Here, a record is one line, so a hundred records are a hundred lines, and scanning down the file becomes scanning down a table. The cost is that this is not the JSON layout most tooling expects to see.

The README shows the shape of the output with nearly default settings:

```json
{
    "BasicObject"   : {
        "ModuleId"   : "armor",
        "Name"       : "",
        "Locations"  : [
            [11,  2], [11,  3], [11,  4], [11,  5], [11,  6], [11,  7], [11,  8], [11,  9],
            [11, 10], [11, 11], [11, 12], [11, 13], [11, 14], [ 1, 14], [ 1, 13], [ 1, 12],
            [ 1, 11], [ 1, 10], [ 1,  9], [ 1,  8], [ 1,  7], [ 1,  6], [ 1,  5], [ 1,  4],
            [ 1,  3], [ 1,  2], [ 4,  2], [ 5,  2], [ 6,  2], [ 7,  2], [ 8,  2], [ 8,  3],
            [ 7,  3], [ 6,  3], [ 5,  3], [ 4,  3], [ 0,  4], [ 0,  5], [ 0,  6], [ 0,  7],
            [ 0,  8], [12,  8], [12,  7], [12,  6], [12,  5], [12,  4]
        ],
        "Orientation": "Fore",
        "Seed"       : 272691529
    },
    "SimilarArrays" : {
        "Katherine": ["blue",       "lightblue", "black"       ],
        "Logan"    : ["yellow",     "blue",      "black", "red"],
        "Erik"     : ["red",        "purple"                   ],
        "Jean"     : ["lightgreen", "yellow",    "black"       ]
    },
    "SimilarObjects": [
        { "type": "turret",    "hp": 400, "loc": {"x": 47, "y":  -4}, "flags": "S"   },
        { "type": "assassin",  "hp":  80, "loc": {"x": 12, "y":   6}, "flags": "Q"   },
        { "type": "berserker", "hp": 150, "loc": {"x":  0, "y":   0}                 },
        { "type": "pittrap",              "loc": {"x": 10, "y": -14}, "flags": "S,I" }
    ]
}
```

Every record in the SimilarObjects array is a single line, and the fields line up in columns across the four records.

## Alignment happens between sibling objects, which is where the readability comes from

The alignment rule is the part that needs a worked example, and the README provides one. Objects with a similar set of keys are written with their fields in columns, so the key names line up vertically and the values line up after them. In the README sample the keys Type, Hp, Loc and Flags appear in the same relative positions across four records, so the eye reads down the Hp column rather than across each record. A record that lacks one of those keys simply leaves that slot empty, which is why the sample shows a pittrap row with the Hp position blank and the Flags value shifted along. This is the practical difference between the formatter and a plain minifier-plus-indenter. A minifier removes whitespace and loses structure for a human; a conventional pretty-printer keeps structure but explodes it vertically; FracturedJson keeps the vertical rhythm of a table while still respecting the nesting of the document.

## Long numeric arrays get packed, several pairs to a line

Arrays of numbers are the case where the compact approach pays off most, because numbers are short and their meaning depends on position rather than on labels. The README sample shows a Locations array of coordinate pairs written eight pairs to a line, with each pair padded so the columns line up within the array. The visual result is a rectangle of numbers rather than a staircase, and a reviewer can compare a column of first coordinates down the page without reading each pair separately. This is also where the compactness stops being merely cosmetic. An array of a few hundred coordinate pairs is a few dozen lines instead of a few hundred, so the file stays reviewable in a diff and does not blow past what an editor handles comfortably. The same packing logic applies to long arrays of any element type, and the format deliberately keeps several items per line rather than one.

## JSONC support keeps comments, and the sample shows how they sit in the output

If enabled in the settings, the formatter can also handle JSON-with-comments. The README includes a JSONC sample to show what that looks like in the output. Multi-line block comments survive and are placed above the element they describe, inline block comments after individual values survive, and trailing line comments after array items survive too, which is what makes the Beatles Songs array in the sample readable with the singer names kept next to each title. The practical question for an adopter is whether comment handling is on by default or is a setting you have to find, since the README phrases it as a setting to be enabled rather than a default behaviour. A tool that silently drops comments would be unacceptable for a configuration file, and one that preserves them but reformats their placement can still surprise you if your tooling diffs the file.

## Three front ends, one set of formatting rules

The repository is home to the .NET versions of FracturedJson, and it carries three of them. The .NET library is available from NuGet as the FracturedJson package. The fracjson command line app is installable from NuGet as a .NET global tool, and is also downloadable from the Releases page as self-contained executables. The browser-based formatter is hosted on GitHub Pages, which lets you paste JSON and see the result without installing anything. That last one is the fastest way to evaluate the format, and it also the easiest way to share the idea with a colleague who will not install a global tool. The project wiki covers formatting options and lists other implementations and ports of the format, which tells you the algorithm itself has been reimplemented elsewhere rather than being tied to this repository. The top level of the tree shows the .NET solution, a Cli directory alongside an OldCli directory, a Tests directory, a Benchmarks directory and a WebFormatter2 directory for the browser version.

## Line length is the knob that decides where the format breaks

The README notes that the sample output was produced with nearly default settings, and names the setting as MaxTotalLineLength=100. That single setting is the heart of the format's behaviour, because the rule that objects stay inline is bounded by it: an object or array that would push the line past the limit is broken out instead, and long arrays are packed several items per line to stay inside it. Everything else follows from that number. Set it high and you get dense lines that scroll sideways; set it low and you get conventional pretty-printing with some compaction on the short values. The formatting options are documented in the project wiki, and the web formatter is the natural place to experiment, since you can see the effect of a length change immediately on your own JSON. A formatter whose output people argue about usually turns out to have one dominant parameter, and for this one the parameter is the total line length.

## Where this is the wrong tool

Two situations stand out. The first is a consumer of the JSON rather than a reader of it. If your build step, test harness or diff viewer expects standard pretty-printed JSON with one key per line, FracturedJson output will look wrong to it, and any tooling that matches on formatting will start producing noisy diffs when the formatter version changes. The second is a machine-to-machine context where compactness is not the goal. If you are generating JSON to be read by a program, the alignment and packing are pure overhead, and a normal serializer that emits one property per line is easier to debug. The format is built for the case where a human reads the file regularly and the structure repeats. If your file has one enormous deeply nested object with no repeated siblings, there is nothing for the aligner to align, and you get the compact single-line treatment without the table benefit.

## A CLI release cadence, a benchmark folder, and the usual .NET project furniture

The release tags are named for the CLI specifically, with cli-v1.1.0 published on 2026-09-27, cli-v1.0.2 on 2026-08-30 and cli-v1.0.1 on 2026-02-21, which tells you the command line tool is versioned separately from the library. The repository is not archived and the last push was on 2026-10-10. Alongside the code you get the standard parts of a .NET repository: a solution file with a DotSettings companion, a CHANGELOG.md, a LICENSE, an AUTHORS-style set of directories for the library, CLI, tests and web formatter, and a Benchmarks directory that indicates performance is tracked deliberately. The licence field is MIT, which is permissive and places no obligation on a commercial product that only uses the library. The wiki is where the formatting options, the web formatter and the list of other implementations live, and it is the reference to read before standardising the formatter across a team, because the settings decide the output.

## Conclusion

FracturedJson suits a developer or team that reads and edits JSON by hand every day, especially with configuration files and game data where the structure repeats and a table-like layout makes diffs readable. It does not suit a pipeline that expects the conventional fully expanded pretty-printed JSON, because the whole point of the format is to deviate from that. Before you adopt it, try the browser formatter on a file of your own to see whether the aligned layout suits how you read JSON, and check the formatting options in the wiki, since the maximum total line length is what decides when an object stays inline and when it breaks apart.

## FAQ

### What is the difference between FracturedJson and a standard JSON pretty-printer?

FracturedJson writes arrays and objects on a single line when they are neither too long nor too complex, aligns sibling fields into columns like a table, and packs long arrays several items per line. A conventional pretty-printer expands every object onto multiple lines.

### Can FracturedJson keep comments in JSON files?

Yes. If enabled in the settings it can handle JSON-with-comments, and the README includes a JSONC sample showing multi-line block comments, inline comments after values and trailing line comments after array items preserved in the output.

### How do I get the fracjson command line tool?

It is installable from NuGet as a .NET global tool under the package name fracjson, and self-contained executables are downloadable from the Releases page. The .NET library itself is published separately as the FracturedJson package on NuGet.

### What controls whether FracturedJson keeps an object on one line?

The MaxTotalLineLength setting, which the README shows set to 100 in its sample output. An object or array that would push the line past that limit is broken out instead, and long arrays are packed to stay inside it.

## Sources

- [Issues](https://github.com/j-brooke/FracturedJson/issues)
- [j-brooke/FracturedJson on GitHub](https://github.com/j-brooke/FracturedJson)
- [License: MIT](https://github.com/j-brooke/FracturedJson/blob/main/LICENSE)
- [README](https://github.com/j-brooke/FracturedJson/blob/main/README.md)
- [Releases](https://github.com/j-brooke/FracturedJson/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/j-brooke-fracturedjson