You open an API endpoint in a new tab to check a response, and the browser shows you a solid wall of text. No indentation, no colors, just one line of braces running off the edge of the screen. Somewhere in there is the field you care about.
A JSON formatter extension fixes this. It detects when a tab is showing raw JSON, validates it, and turns it into a readable, indented, color-coded view, right in the browser, with no copying and pasting into another tool.
This guide covers what a good extension should do, what your browser already does without one, how to judge whether an extension is safe, and how these tools work under the hood. In the second half, we’ll build a small working formatter extension ourselves. That’s the best way to understand the problems the good ones solve, like 64-bit IDs that quietly change and JSON values that can inject HTML into the page.
The logic code was run and tested on Node.js 22, and the content script was tested against a simulated page in jsdom.
What Is a JSON Formatter Extension?
A JSON formatter extension is a browser add-on that automatically formats and validates JSON when you open it in a tab. It replaces the raw text with an indented, syntax-highlighted view, and it usually adds collapsible sections, a raw/formatted toggle, and an error message when the JSON is invalid.
It works on anything the browser opens as a document. That includes API URLs, .json files on a server, and local JSON files if you allow it. It does not touch the fetch() calls your app makes in the background. For those, the Network panel in DevTools is still the right place to look.
Put simply, it’s a JSON viewer that turns on by itself whenever a tab shows raw JSON.
Do You Still Need an Extension?
It depends on your browser. Some browsers now do a good part of this job without any add-ons.
Firefox has a full JSON viewer built in. Open any JSON URL and you get three tabs: a collapsible tree, the raw data (with a Pretty Print button), and the response headers. It also has a filter box, plus Save, Copy, Collapse All and Expand All. For many Firefox users, an extension adds very little.
Microsoft Edge includes a built-in JSON viewer that formats and highlights JSON responses and lets you collapse sections.
Chrome is more basic. Recent versions add a small “pretty-print” checkbox to raw JSON pages, which indents the text. At the time of writing, there’s no tree view, no collapsing and no search. That gap is why JSON formatter extensions are most popular among Chrome users.
Safari shows raw JSON with very little formatting, so Safari users who look at JSON often tend to install an extension.
My practical rule: on Firefox, try the built-in viewer for a week before installing anything. On Chrome, an extension is worth it if you open JSON URLs more than a few times a day.
What Should a Good JSON Formatter Extension Do?
Nearly every extension indents and colors JSON. The differences show up in the details, and a few of those details decide whether the tool helps you or quietly misleads you.
Validation with a precise location. When JSON is broken, “Invalid JSON” is not enough. A good extension tells you the line and column of the error. (If you want to see how that works, our guide on building a JSON error locator walks through converting “position 94” into a line and column.)
Accurate numbers. This is the one most people never check. Many formatters pass the text through JSON.parse(), which rounds integers larger than 2⁵³ − 1. A 64-bit order ID from your database can show up with its last digits wrong. We’ll look at this closely below.
The original key order. Parsing can move keys that look like numbers, such as “2024” or “117”, to the front of an object. If an extension shows you a different key order than the server sent, you may end up debugging a problem that isn’t real. Our article on why JSON.parse() reorders keys explains the rule behind this.
A raw view. You should always be able to switch back to exactly what the server sent.
Collapsing and search. Collapsible nodes and a search or filter box matter once responses get past a few hundred lines.
Copying a path. Being able to click a value and copy its path, such as $.user.orders[0].id, saves time when you’re writing tests or code that reads that field.
Speed on large files. A formatter that freezes the tab on a 50 MB export is worse than no formatter at all.
No data leaving your machine. A formatter has no reason to send your JSON anywhere. It should work fully offline.
Is a JSON Formatter Extension Safe?
A JSON formatter extension is only as safe as the permissions it holds and the people who control its updates. To work on any JSON URL, it usually needs access to every site you visit. In Chrome, the install dialog describes this as permission to “read and change all your data on all websites.”
That permission is normal for this kind of tool. It’s also powerful. The extension can read everything on every page, including internal dashboards, admin panels, and API responses that contain tokens or customer data.
The bigger risk is often not the first version you install but later updates. Extensions update automatically, and popular ones are sometimes sold to new owners. The Great Suspender, a well-known Chrome tab manager, was removed from the Chrome Web Store in 2021 after reports that code added under a new owner was malicious. Nothing about JSON formatters makes them special here. It’s simply a risk that comes with any extension that has broad access.
Here’s how I’d evaluate one before installing it on a work machine:
- Check whether the source is public. An open-source extension with an active repository is much easier to trust, because you can see what it does.
- Look at the permissions. A formatter needs access to pages. It shouldn’t need your browsing history, downloads, cookies or clipboard reading.
- Read the privacy policy. It should say plainly that no data is collected or sent.
- Look at the update history. A sudden change in ownership or publisher name is worth a second look.
- Limit site access if you can. Chrome lets you set an extension to run only “on click” or only on specific sites. If you mostly look at your own API, restrict it to that domain.
If your company manages your browser, check with your security team first. Some organizations only allow extensions from an approved list, for exactly these reasons.
How to Install and Use a JSON Formatter Extension
The steps are nearly the same in every Chromium browser, including Chrome, Edge, Brave and Opera:
- Open your browser’s extension store and search for “JSON formatter.”
- Compare a few options using the checks above, then install the one you choose.
- Open any JSON URL. The page should be formatted automatically.
- To format local .json files, open the extension’s details page and turn on Allow access to file URLs. This setting is off by default, and it’s the most common reason formatting “doesn’t work” on local files.
- If you use private or incognito windows, enable the extension there separately. Extensions are off in incognito by default.
Firefox extensions installed from addons.mozilla.org. If you install one there, check whether it replaces the built-in viewer or runs alongside it, since two viewers competing for the same page can cause odd results.
If you’d rather not install anything, you can paste JSON into our JSON Formatter & Validator instead. It formats and validates in your browser, shows the exact line and column of any error, and doesn’t send your data to a server.
How Do JSON Formatter Extensions Work Under the Hood?
Most formatter extensions follow the same five steps:
Page loads → detect raw JSON → validate → format and highlight → replace the viewThe extension adds a content script to every page. When a tab shows a raw JSON document, Chrome displays it as plain text inside a single <pre> element. The content script finds that element, checks whether the text is JSON, parses it, formats it, and inserts a nicer view in its place.
The steps are simple. Doing each one correctly is where the work is. Let’s build one.
Build a Minimal JSON Formatter Extension
This extension uses Manifest V3, the current format for Chrome extensions. It has three files: a manifest, a core logic file with no browser dependencies (so it can be tested in Node), and a content script that connects the logic to the page.
The manifest
{
"manifest_version": 3,
"name": "Mini JSON Formatter",
"version": "1.0.0",
"description": "Formats and validates JSON responses in the browser tab.",
"content_scripts": [
{
"matches": ["<all_urls>"],
"js": ["formatter-core.js", "content.js"],
"run_at": "document_idle"
}
]
}Content scripts listed together share the same scope, so content.js can call the functions defined in formatter-core.js. Using <all_urls> is what triggers the “all websites” warning. For a personal tool, you could narrow it to something like “https://api.yourcompany.com/*”.
Step 1: Detect JSON without guessing too much
The content type is the most reliable signal. But plenty of servers send JSON as text/plain, and many APIs use vendor types such as application/problem+json or application/vnd.api+json.
const JSON_TYPES = /^application\/(.+\+)?json$|^text\/json$/i;
function looksLikeJson(contentType, bodyText) {
const type = (contentType || '').split(';')[0].trim();
if (JSON_TYPES.test(type)) return true;
if (!/^text\/plain$/i.test(type)) return false;
const start = bodyText.replace(/^\uFEFF/, '').trimStart()[0];
return start === '{' || start === '[';
}The function only checks the body’s first character for text/plain. It never tries to treat text/html as JSON. That keeps the extension from rewriting regular web pages that happen to start with a brace.
Step 2: Remove anti-hijacking prefixes
Some APIs start their JSON with a short, deliberately invalid prefix such as )]}’ or while(1);. It’s a defense against an old attack called JSON hijacking (sometimes called XSSI). Angular’s documentation describes the )]}’, convention, and several Google APIs use it too.
If you parse these responses as-is, a formatter reports them as invalid, even though the data is fine. A good formatter removes the prefix first:
const XSSI_PREFIXES = [")]}',\n", ")]}'\n", ")]}'", 'while(1);', 'for(;;);'];
function cleanBody(text) {
let t = text.replace(/^\uFEFF/, '');
for (const p of XSSI_PREFIXES) {
if (t.startsWith(p)) { t = t.slice(p.length); break; }
}
return t;
}This also removes a byte order mark (BOM), which some editors and export tools add to the start of files. JSON.parse() rejects a BOM, and it’s invisible on screen, which makes the resulting error very confusing.
Step 3: Validate and point to the error
When parsing fails, turn the engine’s character position into a line and column:
function locate(text, position) {
const lines = text.slice(0, position).split(/\r\n|\r|\n/);
return { line: lines.length, column: lines[lines.length - 1].length + 1 };
}
function validate(text) {
try {
return { ok: true, value: parseKeepingBigInts(text) };
} catch (err) {
const m = err.message.match(/at position (\d+)/);
const where = m ? locate(text, Number(m[1])) : null;
return { ok: false, message: err.message, ...where };
}
}Splitting on \r\n|\r|\n means files saved on Windows are counted correctly. Not every browser engine includes a position in its error message, so the result may not have a line and column. The display code has to handle that case too.
Step 4: Keep large integers exact
This is the bug I’d check first in any formatter. Look at what JSON.parse() does to a large ID:
console.log(JSON.parse('{"id":12345678901234567890}').id);
// 12345678901234567000JavaScript numbers can only represent integers exactly up to 9,007,199,254,740,991. Anything larger gets rounded. A formatter built on plain JSON.parse() shows you the rounded value. You copy it into a query, and nothing matches.
Picture this: support reports that order 1234567890123456789 doesn’t load. You open the API response in the browser, and your formatter shows 1234567890123456800. Now you’re chasing a data bug that doesn’t exist. The server sent the right number, and your viewer changed it.
Modern JavaScript can avoid this. The source text access feature gives a reviver function the original text of each value, so you can rebuild large integers as BigInt. Node.js 22 and recent versions of Chrome and Edge support it. Check support before relying on it in other browsers.
const SUPPORTS_SOURCE = (() => {
let ok = false;
JSON.parse('1', (k, v, ctx) => { ok = !!(ctx && ctx.source === '1'); return v; });
return ok;
})();
function parseKeepingBigInts(text) {
if (!SUPPORTS_SOURCE) return JSON.parse(text);
return JSON.parse(text, (key, value, ctx) => {
if (typeof value === 'number' && !Number.isSafeInteger(value) &&
ctx && /^-?\d+$/.test(ctx.source)) {
return BigInt(ctx.source);
}
return value;
});
}
function stringifyKeepingBigInts(value, indent = 2) {
return JSON.stringify(value, (k, v) =>
typeof v === 'bigint' ? JSON.rawJSON(v.toString()) : v, indent);
}JSON.rawJSON() tells JSON.stringify() to write the digits exactly as given, without quotes. The value goes in as the exact integer the server sent and comes out the same way. The function only converts integers that aren’t safe, so normal numbers and decimals are left alone.
Step 5: Highlight without creating an XSS hole
The easiest way to add syntax colors is to wrap tokens in <span> tags and set innerHTML. It’s also the easiest way to create a security hole. JSON values are data from the server, and they can contain HTML:
{ "bio": "<img src=x onerror=alert(1)>" }If the formatter adds that string to the page without escaping it, the browser runs it. Every piece of text has to be escaped before it’s wrapped:
const escapeHtml = (s) => s.replace(/[&<>"']/g, (c) =>
({ '&': '&', '<': '<', '>': '>', '"': '"', "'": ''' }[c]));
function highlight(pretty) {
const token = /("(?:\\.|[^"\\])*")(\s*:)?|\b(true|false|null)\b|(-?\d+(?:\.\d+)?(?:[eE][+-]?\d+)?)/g;
let html = '', last = 0, m;
while ((m = token.exec(pretty))) {
html += escapeHtml(pretty.slice(last, m.index));
const cls = m[1] ? (m[2] ? 'key' : 'str') : m[3] ? 'lit' : 'num';
html += `<span class="${cls}">${escapeHtml(m[1] || m[0])}</span>`;
if (m[2]) html += escapeHtml(m[2]);
last = token.lastIndex;
}
return html + escapeHtml(pretty.slice(last));
}Strings match first, so numbers or words like true inside a string are never colored by mistake. Keys are recognized by the colon that follows them. The text between tokens is escaped as well. That text is only whitespace and punctuation, but escaping it anyway costs nothing and keeps the rule simple: nothing reaches innerHTML without being escaped.
Step 6: Copy a JSON path
When you’re writing a test or a data mapping, you often need the path to a value. This helper turns a list of keys and indexes into a readable JSONPath-style string:
function toJsonPath(segments) {
return segments.reduce((path, seg) => {
if (typeof seg === 'number') return `${path}[${seg}]`;
return /^[A-Za-z_$][\w$]*$/.test(seg) ? `${path}.${seg}` : `${path}[${JSON.stringify(seg)}]`;
}, '$');
}
console.log(toJsonPath(['user', 'orders', 0, 'id'])); // $.user.orders[0].id
console.log(toJsonPath(['headers', 'content-type'])); // $.headers["content-type"]Keys with hyphens, spaces or a leading digit use bracket notation, so the path is still valid when you paste it into code.
Step 7: Protect the tab from huge files
Highlighting creates a DOM element for every token. On a large file, that can freeze the tab for several seconds or crash it. Set a limit, and above it, show formatted plain text instead:
const HIGHLIGHT_LIMIT = 2 * 1024 * 1024; // characters
function render(text) {
const result = validate(text);
if (!result.ok) return { kind: 'error', ...result };
const pretty = stringifyKeepingBigInts(result.value, 2);
if (pretty.length > HIGHLIGHT_LIMIT) return { kind: 'plain', text: pretty };
return { kind: 'html', html: highlight(pretty) };
}Two million characters is a starting point, not a rule. Tune it on the machines your team uses. Commercial extensions often go further, rendering only the visible part of the tree or doing the parsing in a background worker.
Step 8: Connect it to the page
The content script finds the raw JSON, renders it, and adds a toggle so you can always see what the server actually sent:
(function () {
const pre = document.querySelector('body > pre');
if (!pre || document.body.querySelectorAll('pre').length !== 1) return;
const raw = pre.textContent;
if (!looksLikeJson(document.contentType, raw)) return;
const result = render(cleanBody(raw));
const out = document.createElement('pre');
out.id = 'mini-json-output';
if (result.kind === 'error') {
out.textContent = `Invalid JSON` +
(result.line ? ` at line ${result.line}, column ${result.column}` : '') +
`\n${result.message}\n\n${raw}`;
} else if (result.kind === 'plain') {
out.textContent = result.text;
} else {
out.innerHTML = result.html; // safe: every value was escaped by highlight()
}
const style = document.createElement('style');
style.textContent = `
#mini-json-output { font: 13px/1.5 ui-monospace, Menlo, Consolas, monospace; white-space: pre-wrap; }
.key { color: #7c3aed } .str { color: #047857 } .num { color: #b45309 } .lit { color: #2563eb }`;
const toggle = document.createElement('button');
toggle.textContent = 'Raw';
toggle.onclick = () => {
const showingRaw = pre.hidden === false;
pre.hidden = showingRaw;
out.hidden = !showingRaw;
toggle.textContent = showingRaw ? 'Raw' : 'Formatted';
};
pre.hidden = true;
document.head.append(style);
document.body.append(toggle, out);
})();Error messages use textContent, never innerHTML, because they include the raw input. The script also exits early unless the page has exactly one <pre> directly inside <body>. That keeps it from touching normal web pages that happen to use a <pre> tag.
To try it, put the three files in a folder, open chrome://extensions, turn on Developer mode, click Load unpacked, and select the folder.
Test the Formatter Logic
Because the core logic doesn’t depend on the browser, you can test it with Node’s built-in test runner:
const test = require('node:test');
const assert = require('node:assert/strict');
const c = require('./formatter-core');
test('detects JSON content types', () => {
assert.equal(c.looksLikeJson('application/json; charset=utf-8', '{}'), true);
assert.equal(c.looksLikeJson('application/problem+json', '{}'), true);
assert.equal(c.looksLikeJson('text/plain', ' [1,2]'), true);
assert.equal(c.looksLikeJson('text/html', '{}'), false);
});
test('strips XSSI prefixes and BOM', () => {
assert.equal(c.cleanBody(")]}',\n{\"a\":1}"), '{"a":1}');
assert.equal(c.cleanBody('\uFEFF{}'), '{}');
});
test('reports line and column for invalid JSON', () => {
const r = c.validate('{\n "a": 1,\n}');
assert.deepEqual([r.ok, r.line, r.column], [false, 3, 1]);
});
test('keeps 64-bit IDs exact', () => {
const text = '{"id":12345678901234567890,"n":1.5}';
assert.equal(c.stringifyKeepingBigInts(c.parseKeepingBigInts(text), 0), text);
});
test('escapes HTML inside values', () => {
const html = c.highlight(JSON.stringify({ bio: '<img src=x onerror=alert(1)>' }, null, 2));
assert.ok(!html.includes('<img'));
});
test('large output skips highlighting', () => {
const big = JSON.stringify(Array.from({ length: 120000 }, (_, i) => ({ id: i, name: 'item' })));
assert.equal(c.render(big).kind, 'plain');
});To export the functions, end formatter-core.js with if (typeof module !== ‘undefined’) module.exports = { … }. The check means the same file works in Node and in the browser, where the module doesn’t exist. All of these tests pass on Node.js 22.
These tests make a good checklist for any extension you’re thinking of installing. Open a response with a 20-digit ID, a )]}’ prefix, and a value containing an <img> tag, and see what happens.
Edge Cases That Trip Up JSON Formatters
These are the situations where formatters, including good ones, most often behave unexpectedly:
- Local files don’t format. File access is off by default. Turn on “Allow access to file URLs” on the extension’s details page.
- Browser pages are off-limits. Content scripts can’t run on chrome:// pages or in the Chrome Web Store, so nothing will format there.
- JSON served as text/plain. Some formatters only check the content type and ignore these responses. Others check the body.
- Vendor content types. Types like application/vnd.api+json and application/problem+json are JSON, but simple checks for application/json miss them.
- Anti-hijacking prefixes. Responses starting with )]}’ or while(1); look invalid unless the prefix is removed first.
- A byte order mark. It’s invisible, and JSON.parse() rejects it.
- Large integers. IDs above 2⁵³ − 1 get rounded unless the formatter handles them specially.
- NDJSON and JSON Lines. Log exports with one JSON object per line aren’t a single JSON document, so a strict formatter reports an error after the first line.
- Comments and trailing commas. Config formats like JSONC and JSON5 allow them. Standard JSON doesn’t, so formatters report them as errors, which is correct.
- Duplicate keys. {“a”:1,”a”:2} parses without an error, but only the last value survives. A formatter that parses first will quietly show only one of the two.
JSON Formatter Extension vs Online Formatter vs DevTools
Each tool fits a different moment in your workflow:
| Tool | Best for | Weak spot |
| Formatter extension | JSON URLs and API responses you open in a tab | Broad permissions; doesn’t see background fetch() calls |
| Browser built-in viewer | Quick checks with no install (strong in Firefox) | Limited in Chrome and Safari |
| DevTools Network panel | Requests your app makes in the background | Awkward for long or deeply nested responses |
| Online formatter | Pasted snippets, sharing, JSON from logs or tickets | You have to paste the JSON in |
| Code editor (VS Code etc.) | Files you’ll edit and save | Too heavy for a quick look at a URL |
Most developers end up using two or three of these. The extension handles URLs, DevTools handles your app’s own traffic, and a paste-in formatter handles everything else, like JSON copied from a log line, a Slack message, or a bug report.
Common Mistakes
Trusting the numbers in the formatted view. If an ID looks slightly wrong, switch to the raw view before assuming the server sent bad data.
Trusting the key order in the formatted view. Keys that look like numbers may have been moved. The raw view shows what the server actually sent.
Installing whatever appears first in the store. A formatter can see every page you visit. Take two minutes to check its permissions, its source code and who publishes it.
Leaving access set to all sites on a work laptop. If you only inspect one or two APIs, restrict the extension to those domains.
Blaming the formatter for invalid JSON. When the extension says the JSON is invalid, it’s almost always right. The server may be returning an HTML error page, truncated output, or a format like NDJSON.
FAQs
What is the best JSON formatter extension for Chrome?
The best one is the one that shows your data accurately and asks for the fewest permissions. Look for open-source code, a clear no-data-collection policy, error messages with line and column, correct handling of large integers, and a raw view. Test any candidate with a large ID and an HTML string before you rely on it.
Does Chrome have a built-in JSON formatter?
Recent Chrome versions add a basic pretty-print checkbox to raw JSON pages, which indents the text. There’s no tree view, collapsing or search, which is why many Chrome users still install an extension. Firefox and Edge have more complete built-in viewers.
Are JSON formatter extensions safe?
They can be, but they usually need permission to read every page you visit. Choose one with public source code and a clear privacy policy, restrict it to the sites you need, and watch for changes in who publishes it. Updates install automatically, so the risk continues after installation.
How do I format a local JSON file in the browser?
Drag the file into a browser tab, or open it with a file:// URL. With a Chromium extension, you first need to turn on “Allow access to file URLs” on the extension’s details page, because it’s off by default. Firefox’s built-in viewer works on local files without extra setup.
Why does my JSON formatter change large numbers?
JavaScript numbers can only store integers exactly up to 9,007,199,254,740,991. A formatter that uses plain JSON.parse() rounds anything larger, so 64-bit IDs lose their last digits. Formatters that handle this read the original text of each number, or display the raw text directly.
Why does the formatter say my JSON is invalid when the API works?
The response may start with a security prefix like )]}’, a byte order mark, or be in a format like NDJSON with one object per line. The API’s own client code removes or handles these, but a strict formatter doesn’t. Check the raw view to see which one you’re dealing with.
Can a JSON formatter extension read my data?
Technically, yes. Any extension with access to a page can read what’s on it, including API responses with tokens or personal data. A trustworthy formatter processes everything locally and sends nothing anywhere. That’s why open-source code and a clear privacy policy matter.
Conclusion
A JSON formatter extension is a small tool that saves you time every day, as long as it shows you the truth. The indentation and colors are the easy part. The details that matter are exact large numbers, the original key order, a precise error location, safe escaping of values, and a raw view you can always switch back to.
Before choosing one, check what your browser already offers, especially if you use Firefox. If you do install one, choose it the way you’d choose any tool that can see every page you visit: public code, the fewest permissions, and access limited to the sites you need.
For JSON that doesn’t come from a URL, like snippets from logs, tickets or chat messages, paste it into our JSON Formatter & Validator to format it, find the exact broken character, and check it before it goes anywhere else.
References: Chrome Developers: Manifest V3 and content scripts · MDN: Firefox JSON viewer · MDN: JSON.parse() and source text access · MDN: JSON.rawJSON() · Angular: XSSI protection · RFC 8259: The JSON Data Interchange Format
