JSON Alexander: a browser extension that replaces the JSON page

The page is replaced, not decorated

JSON Alexander is a browser extension that shows formatted JSON in place of the browser's own rendering of it. The README's description of how it works is short: navigate to any URL that returns JSON, for example a placeholder API, and the extension automatically detects the JSON response and replaces the page with an interactive viewer.

That word automatically is the whole design. There is no button to click, no context menu, no panel to open. You request an endpoint and you get a viewer. For a developer debugging a REST API, the difference between that and opening the same URL in a JSON formatter is the difference between seeing the payload your browser actually received, with its cookies and headers and redirects, and seeing a copy of something you pasted by hand.

The feature list is what you would want from a serious JSON viewer. Syntax highlighting for keys, strings, numbers, booleans and null. A collapsible tree with level controls. Hovering any property to see its full JSON path, with a click to pin that path and then copy it. Inline expand and collapse buttons on an object to open or close all of its children. Three view modes in Tree, Formatted and Raw. Copy to clipboard of the whole JSON. Light, dark and auto themes that follow the system. Indent guide lines with hover highlighting, and an optional custom cursor from the settings panel.

The project is by Wes Bos, the description of it in the README being that George formats JSON. The licence is MIT and the implementation is TypeScript.

The JSON path is the feature that saves the most time

Most JSON viewers can show you a tree. JSON Alexander spends one of its three headline features on the path to a value, and that is the right priority for API work.

The behaviour is described in one line: hover any property to see its full JSON path, click to pin, then copy. The path is what you need when you are translating a nested value into code, and a deep payload makes that translation tedious. With a hover you get the path, a click pins it so it does not vanish when you move the pointer, and the copy button in the toolbar takes it to the clipboard.

The level buttons, labelled 1, 2, 3 and so on up to All, control the depth of the tree that is expanded. That is a small feature with a large effect on large payloads, where the default open state can bury the interesting part under several thousand collapsed rows. Level 1 shows the top level keys, level 2 one level deeper, and All opens everything for the cases where you genuinely need the whole tree.

The three view modes cover three different questions. Tree is for exploration. Formatted is the pretty printed JSON, which is what you want when you are reading a payload as a document or copying it into a bug report. Raw is the unmodified response, which matters when you are checking exactly what the server sent rather than what the parser produced.

The indent guide lines with hover highlighting are a smaller touch that makes long arrays readable, since without them a deeply nested value loses its shape quickly.

Loading it unpacked in Chrome and Firefox

There is a published build for Chrome on the Chrome Web Store, and the README also offers to download and install it yourself. The manual route is the one with steps, and it differs between browsers.

In Chrome you open chrome://extensions, enable Developer mode with the toggle in the top right, click Load unpacked, and select the dist folder inside the project. The dist folder is the build output, which is why the installation instructions cannot be followed on a fresh clone before you build.

In Firefox you open about:debugging#/runtime/this-firefox, click Load Temporary Add-on..., and select the manifest.json file inside dist. The word temporary matters here, since a temporary add-on in Firefox is removed when the browser restarts, so this path is for development and evaluation rather than for daily use.

There is one extra step in Firefox, and it is the step people miss. Firefox has a built-in JSON viewer that can prevent the add-on from taking over JSON pages, so the README instructs you to open about:config, accept the warning prompt, search for devtools.jsonview.enabled, set it to false, and reload any JSON page.

That instruction is a symptom of a broader truth about extensions like this one. A browser extension that replaces page content is competing with the browser's own renderer, and in Firefox that competition is decided by a hidden preference. The extension does not fail loudly here; it simply never takes over.

Two build entry points, one dist folder

The development section gives three commands:

npm run build  # production build
npm run zip    # build and create json-alexander.zip

The third script, `npm run dev`, is the watch mode that rebuilds on file changes.

The build script in package.json shows how the pieces fit together, and the mechanism is the interesting part. The build command runs ENTRY=content vite build and then ENTRY=page-script vite build, so the project produces two bundles from one source tree, selected by an environment variable named ENTRY. The dev script does the same with the watch flag.

That structure matches what the extension has to do. A content script runs in the context of the page and can see the response, while a page script runs in the page's own world, and the split is the standard way to build an extension that needs both. The vite.config.ts at the root and the vite-plugin-static-copy dependency handle the copying of static assets into the output.

The zip script builds and then zips the dist directory into json-alexander.zip at the repository root, and that archive is committed alongside the dist folder itself. The repository listing shows both, plus icons/ for the extension icons and src/ for the sources.

The toolchain is deliberately small: TypeScript, Vite, the Chrome type definitions, and Node types. There is no framework in the dependency list, no state library and no test runner, and the package is marked private with version 1.1.0, so it is not published to a registry. This is a project that builds one thing, ships it as a folder, and leaves the packaging to the browser.

window.data and the rest of the workflow

Two details make the extension useful beyond reading.

The parsed JSON payload is available in the console as window.data. For a developer already working in devtools, that means the parsed object is right there, one variable away, without copying the payload into a scratch pad or re-fetching it by hand.

The other detail is the reload step. The README says that after making changes you reload the extension in your browser, which is the normal loop for an unpacked extension: rebuild with the watch command, then hit reload on the extension page. There is no hot reload into the page and no plugin architecture, so the cycle is deliberate and manual.

The interaction list in the usage section is short and worth reading as a description of the whole interface. The level buttons control tree depth. The view picker switches between Tree, Formatted and Raw. The theme toggle cycles between auto, dark and light. Copy JSON takes the full payload to the clipboard. Clicking any line pins the JSON path in the toolbar, where Copy takes it. The console holds window.data. And the settings gear, marked in the README with a gear symbol, toggles the custom cursor.

That last one is a preference rather than a feature, and it is a reminder of what this project is: a viewing tool that somebody tuned for themselves and shared.

Where JSON Alexander stops

The limits are clear from the design.

First, it only sees what your browser sees. The extension works on responses fetched by the browser, so anything you open in a tab, or an API call made with the session cookies of your profile, is covered. Anything fetched by a server, a mobile app or a background job is not, and pasting the payload into an online formatter means handing it to a third party.

Second, Firefox needs its native viewer disabled, and the fix is a hidden preference in about:config. A user who installs the add-on, sees nothing happen, and does not read the README will conclude the extension is broken.

Third, it is a page viewer, not an API client. There is no request builder, no header editor, no response timing, no collection of requests into a workspace. If your problem is comparing many endpoints and their headers, this is the wrong shape of tool, and a dedicated API client is the right one.

Fourth, the release story is thin. The repository publishes no GitHub releases, the package version in package.json is 1.1.0, and the last push was on 2026-04-20. The Chrome Web Store listing is the versioned artefact for users, while anyone building from source is building from the main branch. The bundled dist folder and the json-alexander.zip in the repository are a convenience for trying it, and they are also a potential source of confusion about which code you are actually running, since a stale dist will load in preference to a fresh build if you forget to rebuild.

With those caveats, the scope is modest on purpose: it does one thing, does it in the browser, and does it without asking for an account.

Editorial conclusion

Adopt JSON Alexander if you debug APIs in the browser and want a tree view with copyable JSON paths on responses that need a session cookie to fetch. Do not expect it to work on Firefox without first setting devtools.jsonview.enabled to false, and remember it only renders responses served inside the browser. Before you build from source, check that the dist folder in the repository matches your browser, note the package version is 1.1.0 with no GitHub releases, and that the last push was on 2026-04-20, so your build comes from the branch rather than a tag.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wesbos/JSON-Alexander on GitHub