How to format json for readable code reviews and prs
- Step 1Save the fixture you are about to commit — Before
git add, take the modified.jsonfixture, mock, or seed file. The tool reads a file (drop or browse) — there is no paste box — so work directly from the file on disk. - Step 2Drop the file onto the prettifier — Drag the
.jsonfile onto the dropzone or clickbrowse. It is read in-browser viafile.text(); nothing uploads, which matters for fixtures that contain sample secrets or customer-shaped data. - Step 3Match the project's indent width — Pick
2 spaces(Node/React/TypeScript convention, the default) or4 spacesto match your.editorconfig. Those are the only two widths — there is no tab setting, so a tab-indented repo needs Prettier instead for byte-exact agreement. - Step 4Decide on key sorting per file type — Turn
Sort keys alphabeticallyON for pure data fixtures and seed files where order is meaningless — this kills order churn. Leave it OFF forpackage.json,tsconfig.json, and config where key order can matter. - Step 5Prettify and copy back into the file — Click Prettify JSON, then Copy the full output (the on-screen preview truncates at 5,000 chars but Copy/Download do not) and paste it over the file content. Ensure the file keeps its trailing newline if your repo's linter expects one.
- Step 6Commit, then verify the diff is clean — Run
git diff --stat— a well-formatted change should touch only the lines you actually edited. If the whole file still shows as changed, the indent width or key-sort choice differs from how the file was last committed; align them and re-run.
Sort-keys decision by file type
Whether to enable key sorting depends on whether the file's key order carries meaning. Use this matrix before committing.
| File | Sort keys? | Why |
|---|---|---|
| Data fixtures / API mocks | On | Order is meaningless; sorting stops re-generated fixtures from showing phantom key-order diffs |
| Database seed JSON | On | Deterministic key order means a re-seed produces a no-op diff |
package.json | Off | Convention places name/version/scripts first; some tooling and humans rely on that grouping. Sorting scrambles it |
tsconfig.json / .vscode/*.json | Off (and fix first) | These are JSONC — comments/trailing commas won't parse here. Repair with json-format-fixer, and keep author-intended order |
Snapshot fixtures (Jest __snapshots__) | Off | Jest owns the format; reformatting by hand causes the next test run to rewrite it anyway |
Diff-noise sources this tool removes (and ones it cannot)
What prettifying fixes for clean PRs, and the cases that need a different tool or a producer change.
| Diff-noise source | Fixed by prettifier? | How / alternative |
|---|---|---|
| Minified one-line fixture | Yes | Re-indent to 2/4 spaces so each value is its own line |
| Inconsistent indentation (mixed 2/4) | Yes | Re-emit at one chosen width |
| Key order varies between regenerations | Yes (data files) | Enable Sort keys — recursive, all objects |
| Trailing comma / comment churn (JSONC) | No | Won't parse — repair with json-format-fixer first |
| CRLF vs LF line-ending drift | No | Handle with .gitattributes / core.autocrlf; the tool emits LF |
| Tab-indented house style | No | Only 2/4 spaces available — use Prettier with useTabs: true |
Free vs Pro for fixture sweeps
Per-file limits from the centralized JSON tier table. For formatting many files at once, CI Prettier is the right tool — this prettifier is one document at a time.
| Tier | Max file size | Batch files (JSON) |
|---|---|---|
| Free | 2 MB | 1 |
| Pro | 100 MB | 10 |
| Pro + Media | 500 MB | 50 |
Cookbook
Before/after fixtures from real review situations. Data is synthetic.
One-line fixture becomes a reviewable diff
ExampleA seed file was committed minified. After prettifying at 2-space, the next change to a single field shows as a one-line diff instead of a full-file rewrite.
Committed (minified):
{"users":[{"id":1,"role":"admin"},{"id":2,"role":"user"}]}
Prettified once and re-committed:
{
"users": [
{ "id": 1, "role": "admin" },
{ "id": 2, "role": "user" }
]
}
Now changing role of id 2 -> a single +/- line in the PR.Sort keys kills regeneration churn
ExampleA codegen step emits fixture keys in hash order, so every regeneration reshuffles keys and bloats the diff. Sorting keys on both old and new makes the diff show only real value changes.
Run #1 output: {"name":"Ada","id":1,"tier":"pro"}
Run #2 output: {"tier":"pro","id":1,"name":"Ada"}
Both prettified with Sort keys ON:
{
"id": 1,
"name": "Ada",
"tier": "pro"
}
-> identical bytes, zero diff. A real value change is the
only thing that would now show.Do NOT sort package.json
Examplepackage.json relies on conventional grouping. Sorting keys scrambles it into an unreviewable mess and can confuse tooling. Prettify with Sort keys OFF to normalize whitespace only.
Sort keys OFF (correct):
{
"name": "app",
"version": "1.0.0",
"scripts": { "build": "tsc" },
"dependencies": { "react": "^18" }
}
Sort keys ON (wrong — order lost):
{
"dependencies": {...},
"name": "app",
"scripts": {...},
"version": "1.0.0"
}tsconfig.json with comments won't parse
Exampletsconfig is JSONC. The strict parser rejects it. Repair first, then prettify the cleaned output for the PR.
Input (tsconfig.json):
{
// strict mode for new code
"compilerOptions": { "strict": true, }
}
Result: invalid JSON: Expected ',' or '}' ...
Fix: run json-format-fixer (strips comment + trailing comma),
then prettify the result. Keep author-intended key order.Confirm only intended keys moved
ExampleAfter prettifying both branches of a fixture, run json-diff to prove the PR only changes what you expect — useful when sorting is on and you want reviewers to trust the normalization.
Workflow:
1. Prettify base fixture (Sort keys ON) -> base.pretty.json
2. Prettify branch fixture (Sort keys ON) -> head.pretty.json
3. json-diff base.pretty.json head.pretty.json
-> changed: users[1].role "user" -> "editor"
Nothing else moved; the PR diff is trustworthy.Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
package.json sorted by accident
Convention brokenEnabling Sort keys on package.json alphabetizes top-level keys, pushing dependencies above name and scattering scripts. Some tooling and most humans expect the conventional grouping. This is a recursive sort, so nested scripts and dependencies are also alphabetized. Always prettify package.json with Sort keys OFF.
tsconfig.json / .vscode JSON has comments
Parse errorThese files are JSONC and the strict parser throws invalid JSON: Expected ',' or '}' after property value on the first comment or trailing comma. Repair with json-format-fixer first. Note that fixing strips comments entirely — if the comments are documentation you need, keep them and format the file with your editor's JSONC formatter instead.
Repo uses tab indentation
Unsupported widthOnly 2 or 4 spaces are available — there is no tab option. Prettifying a tab-indented repo's fixtures here will convert them to spaces, which then shows as a whole-file diff against the tab baseline. For tab houses, enforce formatting with Prettier (useTabs: true) in a pre-commit hook instead of this tool.
Fixture with a large integer ID
Silent precision lossIf a seed fixture contains a 64-bit ID like 9007199254740993, JSON.parse rounds it and the committed fixture now holds a different value — a subtle data bug that the PR diff will show as an innocuous-looking number change. Store large IDs as strings in fixtures to avoid it.
Fixture has duplicate keys
Last value winsJSON.parse keeps only the final value for a repeated key, so a hand-edited fixture with an accidental duplicate silently drops the earlier one. The committed file then differs from the author's intent. Review raw fixtures for duplicate keys before relying on the prettifier.
Numeric-string keys reorder regardless of Sort toggle
Engine reorderKeys that look like non-negative integers ("0", "1", "10") are always emitted first in ascending numeric order by the JS engine, even with Sort keys off. A fixture keyed by stringified IDs will therefore reorder on its own — which is fine for diffs as long as it is consistent, but surprising the first time.
Case-mixed keys after sorting
Locale orderSorting uses localeCompare, so Alpha, beta, Gamma sort as Alpha, beta, Gamma, not the ASCII order Alpha, Gamma, beta. If a teammate uses jq -S (code-point order) on the same file, the two outputs differ and you get diff churn. Standardize the whole team on one sorting tool.
Number literals normalized
By design1.0 becomes 1, 1e3 becomes 1000, 0.50 becomes 0.5. The values are equal but the committed text changes, which can surprise a reviewer expecting the literal they typed. This is standard JSON round-tripping, not a bug.
Sweeping dozens of fixtures at once
One file at a timeFree JSON batch is 1 file and even Pro is 10 — this tool formats one document per run. For a repo-wide sweep, add Prettier and run npx prettier --write '**/*.json' in a pre-commit hook or CI. Use this tool for spot-fixing a single fixture during review.
Fixture exceeds the tier file limit
Rejected — over tier limitA fixture over 2 MB is blocked on free tier with an upgrade prompt; Pro raises the limit to 100 MB. Very large seed files are also better handled by a CI formatter than copy-paste — the in-browser preview truncates at 5,000 characters (display only).
Frequently asked questions
How do I make JSON fixtures produce clean PR diffs?
Prettify each fixture to your project's indent width before committing, and enable key sorting for pure-data files so regeneration order stops causing churn. After that, any future change shows as a line-level diff. For team-wide enforcement, also add Prettier in a pre-commit hook so the convention is automatic.
Should I sort keys in committed JSON?
It depends on the file. For data fixtures and seed files, yes — sorted keys give stable, no-op diffs on regeneration. For package.json and tsconfig.json, no — those rely on conventional or author-chosen order. The decision table in this guide maps it out; document the policy in your contributing guide.
Why won't my tsconfig.json prettify here?
Because tsconfig.json is JSONC — it permits // comments and trailing commas, which strict JSON.parse rejects. Repair it with json-format-fixer first (note that strips comments), or format it with your editor's built-in JSONC formatter to keep the comments.
Can I match my repo's tab indentation?
No — this tool offers 2 or 4 spaces only. For a tab-indented codebase, prettifying here would introduce a spaces-vs-tabs diff against your baseline. Use Prettier with useTabs: true for byte-exact agreement with a tab house style.
Does prettifying change my data and risk a silent regression?
Only through standard JSON round-tripping: large integers (> 2^53−1) lose precision, duplicate keys collapse to the last value, and number literals canonicalize (1.0 → 1). For typical fixtures none of these apply and the change is whitespace-only. Watch the first two if your fixtures contain big IDs or were hand-edited.
How do I prove to reviewers that only intended keys changed?
Prettify both the base and branch versions with the same settings, then run json-diff to get a structural change list. That separates the normalization (whitespace/order) from the real change, so reviewers can trust a large textual diff that is mostly reformatting.
Can I format every JSON file in the repo in one go?
Not with this tool — it handles one document per run (free batch is 1 file, Pro is 10). For a repo-wide sweep, install Prettier and run npx prettier --write '**/*.json', ideally wired into a husky + lint-staged pre-commit hook and a CI prettier --check gate.
Will the output match what Prettier produces?
Close, but not guaranteed byte-identical. Prettier has its own spacing rules (e.g. inline objects vs always-multiline) and code-point key sorting; this tool follows JSON.stringify with locale-aware sorting. Pick one tool as the canonical formatter for the repo to avoid back-and-forth churn.
Does it preserve my file's trailing newline?
JSON.stringify does not add a trailing newline, so paste carefully if your linter (eol-last) requires one — add it back after pasting. The downloaded file follows the same rule. Configure your editor or Prettier to enforce the final newline consistently.
Are my fixtures uploaded when I format them?
No. The file is read with file.text() and parsed/formatted entirely in your browser. Fixtures, mocks, and seed data — including any sample secrets — never reach JAD Apps servers. Only an anonymous run counter is stored when signed in.
What happens with a snapshot test fixture?
Jest owns the format of __snapshots__ files (they are JS, not pure JSON, and follow Jest's serializer). Don't hand-prettify them — the next jest -u run rewrites them anyway. Format only your own data fixtures and mocks.
Can I automate fixture formatting in CI without the browser?
Yes via the Pro runner: the json-prettifier bundle mirrors this tool exactly (indent 2/4, optional sortKeys, trim-then-parse). But for a CI gate across many files, Prettier with prettier --check is usually the better fit — it fails the build on any unformatted file.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.