Review a JSON Configuration Change with Formatting, Diff, and SHA-256

When a configuration change looks small, separate three questions: is the JSON valid, what changed, and which exact file are we handing over? Use JSON Formatter for syntax and readability, Text Diff for the review, and Hash Generator for a fingerprint of the final saved bytes. None of these steps proves the configuration is correct for the application.

This workflow is useful for a small non-sensitive config, an example API response, or a settings file you need to review with a colleague. Keep production credentials out of examples and follow your organization's rules for browser tools.

Define the intended change before comparing files

Suppose the approved change is to increase a timeout from 3000 milliseconds to 5000 milliseconds. The retry count and enabled flag should stay the same.

Before:

{"timeoutMs":3000,"retry":2,"enabled":true}

After:

{"timeoutMs":5000,"retry":2,"enabled":true}

These are synthetic settings, not a recommended configuration for a particular service. The intent is explicit: one value changes. That gives the reviewer a target instead of asking them to infer what the author meant from a block of JSON.

Keep both original files. A formatting pass should create a review copy rather than silently replacing the only source you have.

Step 1: Validate and format both versions consistently

Open JSON Formatter, paste the first version, and choose Format with a consistent indentation setting. Repeat for the second version.

The formatted first version is easier to inspect:

{
  "timeoutMs": 3000,
  "retry": 2,
  "enabled": true
}

Use the same indentation for both versions. Otherwise, whitespace differences can obscure the one change you wanted to examine.

If the parser rejects the input, fix the source deliberately. Strict JSON does not allow comments or trailing commas. A file accepted by a JSON-with-comments configuration system may therefore fail a strict JSON formatter without being invalid for that particular application.

Do not remove comments from a live config solely to satisfy a tool without understanding the application's format. Work with a safe review representation when the source format differs.

Know what formatting can change

A browser formatter generally parses and serializes JSON. That is more than arranging the original characters visually. Duplicate keys can be collapsed, and very large numeric values can lose precision in JavaScript number handling.

For example, an integer identifier larger than JavaScript's safe integer range should not casually be run through a parse-and-stringify workflow and then treated as byte-preserved evidence. A formatter is also not a canonical JSON implementation simply because it produces attractive indentation.

If exact numeric representation, duplicate keys, signatures, or canonical serialization matter, use a format-aware workflow designed for that requirement. The small integers in this example avoid those special cases.

Syntax validity still does not establish semantic validity. "timeoutMs": -1 may be valid JSON and invalid for your application. A string "5000" may parse but have a different type from the number 5000. Apply the application's schema, tests, and operating constraints separately.

Step 2: Compare the readable versions

Open Text Diff. Put the formatted original on the left and the formatted revision on the right, then compare. Unified view is useful for a compact review; Side by Side can make longer passages easier to follow.

For the example above, the live result showed one removed line, one added line, and four unchanged lines. The changed pair was:

-  "timeoutMs": 3000,
+  "timeoutMs": 5000,

That is the expected textual change. It is not a claim that two business operations occurred: a replaced line is commonly represented as a removal plus an addition.

Inspect the surrounding context as well. Confirm that retry remains 2 and enabled remains true. Check units in the application documentation; increasing a setting named in milliseconds is very different from increasing one interpreted as seconds.

Text difference is not semantic difference

Reordering object keys can create a noisy text diff even when the application treats the objects as equivalent. Changing whitespace can alter file bytes without changing parsed data. Conversely, changing an array's order may materially change behavior.

Do not sort arrays just to make a comparison look cleaner. If you introduce a normalization step, document it and preserve the original inputs. For a large nested configuration, a dedicated structural diff or schema-aware test may be more appropriate than a general line comparison.

ToolKnit's current Text Diff also has input and comparison-work limits. Split large reviews into meaningful sections when necessary; do not assume a browser can compare arbitrarily large documents just because the text fits on disk.

Step 3: Save the approved file, then hash that file

After review, save the intended final file in your normal editor. Open Hash Generator, choose File, and select the actual saved artifact. Use SHA-256 when recording its fingerprint.

File mode matters because a pasted text version can differ from the saved file. Line endings, a trailing newline, a byte-order mark, encoding, and indentation all affect the bytes being hashed. If the delivery question is “did you receive this exact file?”, hash the file rather than a visually similar pasted string.

The text input can still be useful for learning. As a check, we entered exactly abc, without a newline, and the live SHA-256 value matched an independent local calculation:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

That test verifies the displayed digest for one known text input. It is not a file-transfer test or a security audit of the whole application.

Step 4: Send a useful review note

Alongside the final file, provide the purpose, scope, and checksum. A concise handoff template is:

File: service-settings-review.json
Intent: Increase timeoutMs from 3000 to 5000.
Unchanged: retry = 2; enabled = true.
Validation: JSON syntax checked; application-specific tests recorded separately.
SHA-256: [digest calculated from the final saved file]

Replace the placeholder with the actual digest; do not reuse the abc value above. The recipient should hash their received copy using the same algorithm and compare the complete value.

A matching hash demonstrates agreement with the bytes behind the trusted reference digest. It does not identify the author, prove that the configuration is safe, or establish that a download is malware-free. If an attacker can replace both a file and its advertised hash, the comparison alone does not authenticate the source.

A short decision table

Problem	Appropriate next step
The JSON will not parse	Inspect syntax and the actual source format
The diff is mostly whitespace	Format review copies consistently
Keys moved and the diff is noisy	Consider structural comparison; preserve originals
A huge integer changes after formatting	Stop parse-and-stringify normalization; use precision-preserving tooling
The file hash differs but text looks identical	Check encoding, line endings, trailing newline, and exact file selection
Everything matches but the app fails	Check schema, units, dependencies, and application behavior

The three tools keep this small review organized: readability, change inspection, and byte identity each have a distinct job. Keep their conclusions separate and your handoff becomes easier to trust.

These operations process the entered material locally. Ordinary website analytics and page-resource requests are separate; see the privacy policy. Local processing does not replace your organization's handling requirements for secrets or confidential configuration.

Checked October 29, 2026 with synthetic JSON. Formatting, the one-line replacement diff, and the abc SHA-256 digest were verified. Application behavior and an actual recipient-side file transfer were not tested. Drafted with AI assistance.