When an API response shows up as unreadable in Chrome, the problem is almost always one of three things: missing Content-Type headers, a response size that blows past DevTools’ formatting limit, or an extension interfering with Chrome’s built-in JSON renderer. The good news is that each of these has a direct fix, and for most developers the issue resolves in under two minutes. This guide covers every cause and every fix, ordered by how often each one actually solves the problem.

Quick Fix

1. Open DevTools (F12), go to Network tab
2. Click the API request, select the Response tab
3. Right-click the response body, choose “Copy response”
4. Paste into DevTools Console: JSON.stringify(JSON.parse(clipboard_contents), null, 2)

Why API Responses Become Unreadable in Chrome

Chrome’s rendering pipeline makes decisions about how to display response content within milliseconds of receiving it. Several things can push that decision toward raw text mode rather than formatted output.

The Content-Type Header Problem

Chrome’s JSON renderer activates only when a server explicitly declares Content-Type: application/json in its response headers. When that header is missing, wrong, or set to something like text/plain or application/octet-stream, Chrome treats the body as generic text. You see a wall of minified JSON instead of an organized tree.

This is the most common cause. Local development servers, Express.js apps missing res.json() calls, and some REST frameworks default to bare responses without proper MIME types. A quick check in the Network tab’s Headers section reveals whether this is the culprit within seconds.

DevTools Response Size Limits

Chrome DevTools applies formatting only to responses under approximately 10MB. Above that threshold, the Response tab displays raw text to prevent the browser from freezing while rendering large object trees. This limit is not configurable through standard settings.

If you regularly work with large API payloads, this will hit you repeatedly. The response arrives correctly from the server but DevTools makes an intentional choice to skip formatting for performance reasons.

“Fix memory problems with Chrome DevTools. Use the Memory panel to find memory leaks and optimize garbage collection across your application.”

Source: Fix memory problems with Chrome DevTools — developer.chrome.com

Extension Interference

Ad blockers and privacy extensions sometimes strip or modify HTTP response headers before Chrome’s parser reads them. When uBlock Origin or Privacy Badger intercepts a response from a domain on their blocklist, they may remove the Content-Type header entirely. Chrome then defaults to text rendering because the signal it needs never arrived.

This cause is easy to test: open the same API URL in an incognito window where extensions are disabled. If the response formats correctly in incognito mode, an extension is the source of the problem.

How to Fix Unreadable API Responses in Chrome

Fix 1: Check and Correct Server Headers

Open DevTools, go to the Network tab, and click the API request. In the Headers section, look at Response Headers for content-type. If it shows anything other than application/json or application/json; charset=utf-8, fix it at the server.

For Express.js: replace res.send(data) with res.json(data), which sets the correct header automatically. For Apache, add AddType application/json .json to your .htaccess file. For Nginx, add the MIME type to your mime.types configuration.

Fixing the header resolves the problem permanently for every future request to that endpoint without any browser-side changes required.

Fix 2: Use the DevTools Console Formatter

When you cannot control the server, the Console tab in DevTools gives you a manual but reliable path. Copy the raw response from the Response tab, then run this in the Console:

JSON.stringify(JSON.parse(`PASTE_RAW_JSON_HERE`), null, 2)

For multi-step inspection: assign the parsed result to a variable, then expand it interactively in the console output. The console handles responses up to 50MB and works regardless of what headers the server sent.

Fix 3: Enable Chrome’s Native JSON Viewer Flag

Navigate to chrome://flags/#enable-json-viewer and set it to Enabled, then restart Chrome. This flag activates Chrome’s built-in JSON viewer for responses that have the correct Content-Type header but are not rendering as formatted output.

Note that this flag only helps when the header issue is already resolved or when Chrome’s viewer is simply disabled. It does not override the 10MB size limit and it will not format responses with incorrect headers.

Fix 4: Disable Extensions Temporarily

Open an incognito window (Ctrl+Shift+N on Windows, Cmd+Shift+N on Mac) and test the API URL there. If the response renders correctly in incognito, an extension is blocking proper formatting in your regular profile.

Go to chrome://extensions/ and disable your ad blocker or privacy extension, then reload the page and retest. Once you identify the conflict, you can add the API domain to the extension’s allowlist rather than keeping it disabled permanently.

Fix 5: Force a Hard Reload to Clear Cached Headers

Chrome caches content-type associations for specific URLs. If a server previously sent malformed headers and you have since fixed them, Chrome may continue using the old rendering behavior until you force a full cache clear.

Hold Shift and click the reload button while DevTools is open. This triggers a hard reload that bypasses all cached responses. Alternatively, right-click the reload button while DevTools is open and select “Empty Cache and Hard Reload.”

Fix 6: Use JSON Formatter Pro for Permanent Relief

“Comprehensive 2025 guide comparing the best JSON formatter tools and Chrome extensions for developers.”

Source: Best JSON Formatter Tools 2025 — superjson.ai

Manual fixes work, but they require repeating the same steps every time you hit a new endpoint with header problems. JSON Formatter Pro intercepts JSON responses before Chrome’s rendering pipeline makes its decision, which means it formats the response correctly regardless of what headers the server sent.

The extension maintains a 4.8/5 rating and handles JSON5, JSONP, and non-standard MIME types that Chrome’s native viewer skips entirely. At 738KiB it adds no perceptible weight to the browser, and it operates entirely locally without sending response content to external servers.

Install once, and every API response in Chrome gets properly formatted collapsible trees with syntax highlighting, regardless of server configuration.

Get JSON Formatter Pro at zovo.one

Quick Fix Summary

Why This Happens: The Technical Background

Chrome’s content negotiation system relies on the HTTP Accept header to signal to servers what format the browser expects, and it relies on Content-Type in the response to determine how to render what it receives. When these signals misalign, the renderer defaults to the safest option: show it as text.

This design choice is intentional. Chrome prioritizes security over convenience, and rendering arbitrary content as executable JSON could expose users to injection attacks if Chrome’s parser made incorrect assumptions. The tradeoff is that developers working with non-standard APIs get raw text instead of formatted output.

FAQ

Why does the same API format correctly in Firefox but not Chrome?

Firefox uses more permissive content-type detection and will attempt JSON formatting even when headers are incomplete or missing. Chrome requires explicit application/json declarations. This is a deliberate difference in how the browsers balance developer convenience against security policy.

Can I see the full JSON response when DevTools truncates it?

Yes. Right-click the response in the Network tab and select “Save response body” to download the complete response as a file. You can then open it in any JSON viewer or editor without Chrome’s size limitations.

Does JSON Formatter Pro send my API responses to external servers?

No. The extension parses and renders responses entirely within your browser. No response content, URLs, or authentication tokens leave your machine. This makes it suitable for use with private APIs and sensitive development environments.

Why do some endpoints format correctly while others do not?

The difference is almost always server configuration. Endpoints that format correctly are sending Content-Type: application/json in their response headers. Endpoints that show raw text are either missing that header, sending a different MIME type, or returning responses large enough to trigger DevTools’ formatting size limit.

Built by Michael Lip — More tips at zovo.one