JSON Formatter for Chrome: What callumlocke/json-formatter Actually Does

The problem: a JSON response is a wall of text in the browser

Open an API endpoint in Chrome and you get the response body as one unbroken string. The browser has no tree, no folding, no highlighting, and no way to jump into a nested object without scrolling. Copying it into an editor works, but it breaks the loop of clicking through an API while you are building against it.

callumlocke/json-formatter is a Chrome extension that intercepts JSON pages and replaces that wall with a parsed, collapsible view. The README describes it as an extension that "helps you view and explore JSON API responses." The intended user is a developer who keeps a browser tab open on an endpoint and reloads it constantly. It is not a validator, a schema checker, or an editor plugin. The README is explicit that it "works on any valid JSON page, URL doesn't matter," so it is not tied to a particular host or content type.

How detection and rendering work

Detection is the hard part, and the README does not pretend otherwise. It says detection "turns out to be a complex thing to get right in a bulletproof way," and describes a two-step approach: in most cases the extension looks at the Content-Type header, and in some cases it inspects the page structure "and see if it looks like a JSON endpoint." The stated design goal is speed, with "no perceivable impact on browsing." The README puts the cost on non-JSON pages at less than 1 millisecond.

Once a page is identified, the extension renders a tree with syntax highlighting, collapsible nodes and indent guides, plus clickable URLs. Two buttons switch between raw and parsed JSON. The parsed object is also exposed as a global variable named json, so you can type json in the console and inspect it with the browser's own tools. That last feature is marked in the README as "now working again," which tells you it has broken before.

The important architectural fact is that the tree is a view of JSON.parse output. The README states this directly: what you see is "a representation of the parsed object/array," and it matches Object.keys(JSON.parse(json)). That single decision explains both the accuracy of the tree and its two documented surprises, the number precision and the key ordering.

Installing it and reading your first response

The README gives two installation paths. The first is the Chrome Web Store listing. The second is building from source. To build, clone the repository and install dependencies with bun, then run a build. The README lists bun install, bun run build for a single build, and bun run watch for a watch-driven build.

bun install
bun run build

The build writes to dist. The README says you can then "install dist as a local, unpacked extension in Chrome with developer mode enabled." After loading it, open any JSON endpoint in a new tab. You should see the parsed tree instead of raw text, with the Raw and Parsed buttons available and collapsible nodes on objects and arrays.

The repository also ships sample files under samples/, including samples/ok.json and samples/broken1.json, which are useful for checking that detection and the broken-JSON path behave as you expect before you point the extension at a real API. The package.json defines the build scripts as bun run task/build and bun run --watch task/watch, so the README commands are thin wrappers over the task directory.

Large numbers and key order: the two documented surprises

The extension shows parsed values, and parsing changes some values. The README states that anything over Number.MAX_SAFE_INTEGER (2^53 - 1, or 9007199254740991) is adjusted down to that number, anything below Number.MIN_SAFE_INTEGER (-2^53 + 1, or -9007199254740991) is adjusted up, and extremely precise floating point numbers are rounded to 16 digits. It is careful to say this is not the extension's doing: it is native JSON.parse in V8. If an API needs to represent numbers outside that range, the README's answer is that it should quote them as strings.

Key ordering is the second surprise. Numeric string keys such as "1" or "99999" are moved to the top, because V8 did this as an optimisation and the behaviour was later standardised. So a payload whose keys arrive in one order can render in another. The README's workaround is the Raw button, which shows what the server sent. It also mentions a possible future change: switching from JSON.parse to a custom parser, "if performance allows," so the extension could warn when parsing has changed a value. That is a stated intention, not a shipped feature.

Both behaviours are the same ones your application will see when it calls JSON.parse, which is the honest framing the README uses. If you are debugging a display bug in your own app, the extension is showing you the right thing. If you are inspecting a wire format, the Raw view is the one you want.

Where it is the wrong tool

It is a browser extension for viewing responses, not a validator. The README never claims schema validation, JSON Schema support, or linting, and the related search phrase "json formatter and validator" describes a job this project does not advertise. If you need to check a document against a schema, look elsewhere.

It is also the wrong choice when you are not in Chrome. The installation section covers the Chrome Web Store and a local unpacked build in Chrome; the README does not describe Firefox, Safari or an editor extension, and the related searches for VS Code, Notepad++ and Sublime Text point at other tools entirely. And it is the wrong tool for exact numeric inspection, for the reasons above. If your payload carries 64-bit identifiers, the parsed view is not the source of truth; the Raw view or a command line tool is.

One more boundary: the README says it works on any valid JSON page, so invalid JSON is outside the promise. The samples directory contains a broken1.json sample, but the README does not document what the extension does with it.

How it compares with a CLI formatter

The closest alternative for many workflows is a command line formatter such as jq, or the pretty-print features built into editors. The difference is where the JSON comes from. A CLI tool needs the payload in a pipe or a file, which means an extra copy step every time you want to look at a response. The extension removes that step: you reload the tab and the tree is already there, with the parsed object available as json in the console.

A CLI tool also keeps the bytes. jq and similar tools can preserve or report values that JSON.parse would round, and they do not reorder keys, so they are the better instrument for exact inspection. The extension trades that exactness for immediacy and for a UI that folds large documents. A reasonable split is to use the extension while navigating an API and reach for a CLI tool when a value looks wrong. The README's own advice points the same way: when you want exactly what the server sent, use Raw.

Maintenance, build cost and licence

The repository is not archived, and the last push was on 2026-09-04. Releases listed are v0.8.0 and v0.7.4, both dated 2025-09-19, and v0.7.2 from 2024-03-27. That release history shows a quiet stretch between March 2024 and September 2025, so the project moves in bursts rather than on a schedule. Plan upgrades around releases, not around continuous churn.

The build is a bun project. package.json lists esbuild, google-closure-compiler, TypeScript, React and Tailwind among the devDependencies, and the scripts route through a task/ directory. Building from source therefore means tracking a modern toolchain, and the README's only documented commands are bun install, bun run build and bun run watch. There is no documented rollback procedure for a local unpacked install; the README does not cover it.

The licence is BSD-3-Clause, which permits redistribution and modification with the licence text retained. That matters if you want to ship a modified build internally. This is a summary of the licence identifier in the repository, not legal advice; read the LICENSE file before acting on it.

Editorial conclusion

Install it if you read JSON API responses in Chrome all day and want collapsible trees, a raw toggle and a json variable in the console; skip it if your payloads carry integers above 9007199254740991 or if you work mostly in an editor. Before adopting it, load a response with a big number and a numeric string key, click Raw, and confirm the parsed view matches what your application will actually see.

Frequently asked questions

Official sources

1. callumlocke/json-formatter on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases