Free · Fast · Privacy-first

Validate JSON API Response

Q: Can an API return Content-Type: application/json but not send JSON?

Yes, this happens frequently in real systems and is a common source of integration bugs. The Content-Type header is set by the route handler that returns the successful response, but error middleware, authentication middleware, or a load balancer sitting upstream from the application can intercept the request and return an HTML or plain-text response without updating the header. The client then sees application/json in the response headers but HTML in the body. Always validate the raw response body itself, not just the Content-Type header, especially when debugging unexpected parse failures.

Q: How do I get the raw API response body to validate?

In browser DevTools, open the Network tab, click the failing request, select the Response tab, and copy the raw response text. In Postman, click the "Raw" view in the response panel to see the unformatted bytes. With curl on the command line, run curl -s https://api.example.com/endpoint and pipe the output to a file or your clipboard. With Node.js fetch in your own code, capture the response with const text = await response.text() before calling JSON.parse(text). Always validate the raw text bytes rather than a pre-parsed object representation.

Q: What does "Unexpected token < in JSON at position 0" mean?

The < character is the first character of an HTML document, either as part of the doctype declaration that starts with <! or as the opening of the html tag. Position 0 means this is the very first character of the response body. The server returned HTML instead of JSON. This typically means one of three things happened: a 404 or 500 error page was returned by the framework, an authentication redirect sent you to a login page rendered as HTML, or a CDN or reverse proxy intercepted the request and returned its own HTML error response without ever reaching your application code at all.

Q: How do I validate an API response in automated tests?

Add a JSON validation step before your main assertion logic in the test setup. In JavaScript with Jest, the pattern is: const text = await response.text(); let data; expect(() => { data = JSON.parse(text); }).not.toThrow(); and then proceed with assertions against data. This produces a clear test failure that includes the raw response text when validation fails, rather than a confusing assertion error against an undefined value further down the test body. The raw text in the failure message makes diagnosis significantly faster when the test fails in CI rather than locally.

API responses are supposed to be JSON, but in practice they often are not.

⚡

Instantly identifies non-JSON response bodies

🔒

Pinpoints exact error position in the response

✨

Works with any REST or GraphQL response

⚡

Free browser tool, no Postman required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this JSON Validator to your website

Drop the JSON Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why API Responses Fail JSON Parsing: Proxies, Status Codes, and Content Negotiation

The single most frequent cause of JSON parse failures on API responses is a mismatch between the Content-Type header the client sees and the actual response body the server sent. A server may correctly set Content-Type: application/json on the route handler but then return an HTML error page when an unhandled exception fires in middleware further up the stack. Load balancers and API gateways frequently have their own error response formats baked in at the infrastructure layer: an NGINX 502 Bad Gateway error returns HTML regardless of the Accept header the client sent. When your client code calls JSON.parse on these responses, the parser sees a < at position 0 and throws immediately. Validating the raw response body reveals whether the failure is a client-side JSON bug or a server-side response format issue.

Authentication failures are another common source of non-JSON API responses that pretend to be JSON. Many web frameworks return an HTML login page, a JSON-looking but actually plain-text "Unauthorized" message, or a redirect to a sign-in page when an API request lacks valid credentials, even when the underlying endpoint was designed to return JSON for successful calls. Authentication middleware that handles credential errors frequently runs before the route handler and uses a different response format than the application code. When you are debugging a 401 or 403 response that your client code cannot parse, paste the raw body into a JSON validator first. If you see HTML or plain text in the validator, the issue is missing or invalid credentials at the boundary, not a JSON parsing bug in your client code.

For developers using interactive tools like Postman or Insomnia during exploration, those tools automatically detect and display JSON responses in a nicely formatted view, but they may not alert you if the raw response actually has subtle issues like a BOM character at byte zero or a JSONP wrapper that a strict JSON.parse would reject. Copying the raw response body out of the tool and validating it in FixTools confirms whether your application code will parse the same response successfully when you move from manual testing to automated integration. FixTools uses the same JSON.parse implementation that your JavaScript runtime will use, so a pass in FixTools is a meaningful guarantee.

Layering response validation into your CI pipeline catches contract violations before they reach production deployments. A typical integration test job spins up the service, sends a representative set of requests through the API, captures each response body, and runs both syntax validation and JSON Schema validation on every captured payload. Tools like Dredd, Postman Newman, or k6 with a small validation hook handle the orchestration cleanly inside GitHub Actions or GitLab CI. For contract testing specifically, Pact validates that the response matches an agreed schema from the consumer side. The cumulative effect is that any change to the serialiser that produces invalid JSON, even for an edge-case input, fails the build instead of slipping through to a customer-facing 500. Pair the automated checks with FixTools for interactive debugging when a captured response fails, and you cover both the bulk batch case and the targeted single-failure case with the same underlying validation logic.

RFC 8259: The JSON Data Interchange Syntax MDN: Using Fetch, checking response types

How to use this tool

💡

Paste the raw body of an API response to confirm it is valid JSON. If the server returned HTML or an error page, the validator will tell you immediately.

How It Works

Step-by-step guide to validate json api response:

1
Copy the raw response body
In your HTTP client of choice, whether browser DevTools Network tab, Postman, Insomnia, or a curl invocation, copy the raw response body. Avoid the formatted or pretty-printed view that most tools present by default, because that view may strip a BOM character or normalise other bytes that affect parsing. Use the raw view or the unprocessed text panel if your tool offers one.
2
Paste into FixTools
Paste the raw response body string into the FixTools JSON validator input area exactly as you copied it. Do not edit, trim, or reformat the text first, since those changes may inadvertently hide the actual issue you are trying to diagnose. The validator needs to see the bytes your downstream parser will see in production.
3
Run validation
Click Validate. If the response is valid JSON, you see a green confirmation and you know the body is parseable. If not, the precise error position is shown along with the token found at that location and the token the JSON grammar expected. This single check determines whether the failure mode lives on the client or the server side of the integration.
4
Diagnose the failure
An error reported at position 0 with the offending character being <, (, or whitespace means the response is not JSON at all. Check the HTTP status code first, then the actual Content-Type header the server returned. A 4xx or 5xx response frequently returns HTML or plain text from an infrastructure layer regardless of what the application Content-Type header was supposed to be for a successful call.
5
Fix the root cause
Address the server-side issue at its source: incorrect authentication handling, error middleware returning HTML instead of JSON, content negotiation misconfiguration, or a reverse proxy injecting its own error pages. Working around invalid response parsing on the client by adding defensive try-catch blocks is a band-aid, not a fix, and it hides the underlying contract violation from monitoring.

Real-world examples

Common situations where this approach makes a real difference:

Mobile developer

A mobile developer is testing an in-app purchase validation endpoint and the app crashes with a JSON parse error on some devices but not others. They reproduce the failing case by copying the raw response from Charles Proxy while running the app under inspection, then paste the captured body into FixTools. The validator shows the response starts with <!DOCTYPE html>, confirming the CDN is returning a cached HTML error page for requests originating from certain geographic regions. The underlying issue is a CDN misconfiguration at the edge, not a bug in the mobile app code at all.

Backend engineer

A backend engineer is building a microservice that calls an external payment API as part of a checkout flow. In staging, every call succeeds without issue. In production, roughly 5% of calls throw a JSON parse error and the engineer cannot reproduce the failure locally. They log the raw response body on failure and paste one captured body into FixTools. The response is technically valid JSON but contains a UTF-8 BOM at position 0 that strict parsers reject. The external API's production environment prepends a BOM that the staging environment does not, and they add BOM stripping before parsing as a defensive measure.

QA engineer

A QA engineer is testing an API contract during a release certification cycle. They use curl to capture 20 different endpoint responses across a range of inputs and paste each raw body into FixTools as part of a manual contract verification step. Three endpoints return HTML error pages for certain edge-case input combinations that fall outside the documented happy path. These three cases are filed as bugs against the API team with the raw response body attached as evidence, making the root cause immediately clear to the developer who picks up the ticket later.

Integration developer

An integration developer is writing a connector between two SaaS platforms for a client project. One platform returns JSON API responses that include a comment-like prefix as a CSRF protection measure: )]}'\n followed by the actual JSON body. FixTools confirms that the raw response is not valid JSON because of the prefix. The developer reads the platform documentation, finds the prefix is officially documented and intentional, and implements a prefix-stripping step before passing the response body to the JSON parser, exactly matching the official guidance from the vendor.

Pro tips

Get better results with these expert suggestions:

Check the HTTP status before parsing

Before calling JSON.parse on an API response body, always check the HTTP status code first. Non-2xx status codes frequently mean the body is not JSON at all, regardless of what the Content-Type header claims, because error responses often come from infrastructure layers that produce HTML by default. A simple guard like if (!response.ok) throw new Error(response.status) before the parse call prevents JSON parse exceptions from masking actual HTTP errors and gives you a cleaner error message that distinguishes between a transport failure and a parse failure.

Log the raw response on parse failure

When JSON.parse fails on an API response in production, log the raw string immediately before the parse call so you have it in your incident diagnostics. A console.log(responseText.slice(0, 200)) showing the first 200 characters of the body is usually enough to identify whether the response is HTML, plain text, malformed JSON, or completely empty. This one defensive logging line saves significant debugging time in production incidents where you cannot easily reproduce the failure path locally on your own machine.

Copy raw, not pretty-printed

When validating an API response in a tool, copy the raw body string, not the formatted version from a browser DevTools JSON viewer or Postman's pretty view. Pretty-printing tools may silently strip a BOM byte, normalise line endings between Windows and Unix conventions, or reformat the content in ways that hide the actual parsing issue your code will encounter in production. Look for a "raw" or "preview" tab in your tool and copy from there to preserve the original bytes exactly as the server sent them.

Validate GraphQL responses too

GraphQL responses are JSON objects with a top-level data key and an optional errors key, and they can fail JSON syntax validation in exactly the same ways REST responses can. If your GraphQL client throws a parse error during a query, paste the raw response into FixTools and check it like any other JSON body. A common cause of GraphQL parse failures is a server crash that returns an HTML 500 page before the GraphQL layer ever gets a chance to handle the request and wrap the failure in a proper GraphQL error structure.

FAQ

Frequently asked questions

The most common reason is that the response body is not actually JSON, despite what the headers claim. Check the raw body: if it starts with < it is HTML, if it starts with ) or ( it may be a JSONP wrapper, and if it is empty the server returned no body at all. Also check the HTTP status code carefully because a 401, 404, or 500 response often returns HTML or plain text from an infrastructure layer regardless of what Content-Type header is set on the route. Validate the raw body in FixTools to confirm what you actually received versus what you expected.

Yes, this happens frequently in real systems and is a common source of integration bugs. The Content-Type header is set by the route handler that returns the successful response, but error middleware, authentication middleware, or a load balancer sitting upstream from the application can intercept the request and return an HTML or plain-text response without updating the header. The client then sees application/json in the response headers but HTML in the body. Always validate the raw response body itself, not just the Content-Type header, especially when debugging unexpected parse failures.

In browser DevTools, open the Network tab, click the failing request, select the Response tab, and copy the raw response text. In Postman, click the "Raw" view in the response panel to see the unformatted bytes. With curl on the command line, run curl -s https://api.example.com/endpoint and pipe the output to a file or your clipboard. With Node.js fetch in your own code, capture the response with const text = await response.text() before calling JSON.parse(text). Always validate the raw text bytes rather than a pre-parsed object representation.

The < character is the first character of an HTML document, either as part of the doctype declaration that starts with <! or as the opening of the html tag. Position 0 means this is the very first character of the response body. The server returned HTML instead of JSON. This typically means one of three things happened: a 404 or 500 error page was returned by the framework, an authentication redirect sent you to a login page rendered as HTML, or a CDN or reverse proxy intercepted the request and returned its own HTML error response without ever reaching your application code at all.

Add a JSON validation step before your main assertion logic in the test setup. In JavaScript with Jest, the pattern is: const text = await response.text(); let data; expect(() => { data = JSON.parse(text); }).not.toThrow(); and then proceed with assertions against data. This produces a clear test failure that includes the raw response text when validation fails, rather than a confusing assertion error against an undefined value further down the test body. The raw text in the failure message makes diagnosis significantly faster when the test fails in CI rather than locally.

Yes, in most cases both sides benefit from validation. Validating request JSON before sending catches client-side errors before they leave your machine, avoiding a wasted network round trip diagnosing a 400 error that a quick local check would have prevented. Validating response JSON confirms the server is behaving according to the documented contract. In tests, validate both directions during the same assertion. In production code, consider validating responses defensively for any external API where you do not control the server behaviour and cannot guarantee what the body will contain on any given day.

JSONP (JSON with Padding) is a legacy technique for cross-domain data loading that predates CORS. A JSONP response looks like: callback({"key": "value"});. This is not valid JSON at all because it is a JavaScript function call expression wrapping a JSON object literal. Calling JSON.parse on the raw JSONP body throws "Unexpected token c" or whatever character the callback name starts with. If you find yourself receiving a JSONP response, strip the function call wrapper before parsing by extracting just the JSON content between the first ( and the last ) of the wrapper.

Postman may automatically handle some issues that your client code does not. It can strip BOM characters silently before displaying the response, ignore unexpected JSONP wrappers, apply lenient parsing in its rendered view, or normalise line endings during display. Your application code calling JSON.parse is strict. Copy the raw response from Postman's "Raw" view rather than the formatted pretty view, and paste it into FixTools to confirm the bytes match. If FixTools fails on the same input, your code will also fail, and the validator will tell you precisely which byte is causing the problem.

Validating a response means confirming the response body is well-formed JSON that any RFC 8259 parser can read without throwing. Schema validation goes further: it confirms the parsed value contains the required fields, with the expected types, in the expected ranges. The two checks fail for different reasons and produce different error signals. A response that returns HTML instead of JSON fails syntax validation immediately at position zero. A response that returns clean JSON but is missing a required field passes syntax validation cleanly and fails schema validation with a JSON Pointer path identifying the absent field. For full coverage, run both in sequence: syntax first to confirm the bytes parse at all, schema second to confirm the parsed value matches the contract your client code expects. Tools like AJV handle the schema pass once the bytes are clean.