In XMLHttpRequest, what does setting `xhr.responseType = 'json'` change about how you read the result, and why does reading `xhr.responseText` afterwards throw?

## What responseType actually does `XMLHttpRequest` receives bytes. `responseType` is the instruction that tells the browser what to turn those bytes into before handing them to your code. It accepts exactly six values: | value | `xhr.response` holds | | --- | --- | | `''` (default) | a string, decoded as text | | `'text'` | a string, decoded as text | | `'json'` | the value produced by parsing the body as JSON | | `'blob'` | a `Blob` | | `'arraybuffer'` | an `ArrayBuffer` of the raw bytes | | `'document'` | a parsed `Document` (HTML or XML) | Everything lands on the single `xhr.response` property. That is the modern surface, and it is the one to reach for. ```js const xhr = new XMLHttpRequest(); xhr.open('GET', '/api/user'); xhr.responseType = 'json'; xhr.addEventListener('load', () => { console.log(xhr.response.name); // already an object, no JSON.parse }); xhr.send(); ``` ## Why responseText throws `XMLHttpRequest` predates `response`. The original API had `responseText` (a string) and `responseXML` (a `Document`), and nothing else. When `responseType` was added, those two getters were not generalised — they were fenced off, so that a program cannot ask for a string from an object that was never decoded as text. The rules are mechanical: - `responseText` throws `InvalidStateError` if `responseType` is anything other than `''` or `'text'`. - `responseXML` throws `InvalidStateError` if `responseType` is anything other than `''` or `'document'`. So the failure people hit is: they copy an old snippet that reads `xhr.responseText`, then add `xhr.responseType = 'json'` to avoid a manual `JSON.parse`, and the handler now throws on the first line. The fix is to read `xhr.response`. ## Parse failures are silent With `responseType = 'json'`, the browser parses the body once the response is complete. If the body is not valid JSON — an HTML error page from a proxy, a truncated body, an empty 200 — the parse failure is swallowed and `xhr.response` is `null`. No exception is thrown, and the `error` event does not fire (that event is reserved for network-level failure). Code that does `xhr.response.items.forEach(...)` then dies with a `TypeError` on `null` far away from the real cause. If you need to distinguish "server sent nothing" from "server sent garbage", use `responseType = 'text'` and parse yourself, so the `SyntaxError` is yours to catch: ```js try { const data = JSON.parse(xhr.responseText); } catch (e) { // you now know the body was not JSON, and you still have the raw text to log } ``` ## When you may set it `responseType` is a settable property, not an argument to `open()`, and the state machine constrains it: - Setting it while the response is already streaming in or finished — `readyState` of `LOADING` (3) or `DONE` (4) — throws `InvalidStateError`. - Setting it to anything other than `''` on a **synchronous** request in a document context makes `open()` throw `InvalidAccessError`. Typed responses are async-only on the main thread. The safe habit is: construct, `open()`, set `responseType`, attach listeners, `send()`. ## Partial reads `responseType` also decides whether you can watch the body arrive. With `''` or `'text'`, `xhr.responseText` returns however much has been decoded so far while `readyState` is `LOADING`, which is how old streaming-ish code worked. With `'json'`, `'blob'`, `'arraybuffer'` or `'document'` there is nothing meaningful to hand over half-way, so `xhr.response` is `null` until the request reaches `DONE`. ## What it does not do `responseType` is purely a client-side decoding instruction. It sends no `Accept` header, does not ask the server for a particular format, and does not validate the response's `Content-Type`. If you set `'json'` and the server returns XML, you get `null` — not a negotiation error. If you want the server to know what you want, set the header yourself with `xhr.setRequestHeader('Accept', 'application/json')`. The one place `Content-Type` does matter is `'document'`: the browser uses the response's media type to decide whether to parse as HTML or XML, and gives you `null` for a type it will not parse as a document at all.