Test your knowledge: Data Types & the CORS Trap

Question 1 of 6

Which union defines the types `sendBeacon`'s `data` argument accepts?

The Beacon spec delegates the body type entirely to Fetch.

Answer options A string | Blob | ArrayBuffer only B The Fetch BodyInit union: Blob, BufferSource, FormData, URLSearchParams, ReadableStream, string C Any JSON-serializable value D FormData and URLSearchParams only — strings are coerced

data is BodyInit | null. The Beacon spec reuses Fetch's extract algorithm verbatim — which is exactly why Content-Type and CORS mode follow Fetch's rules, not Beacon-specific ones.

Review this lesson

Question 2 of 6

You pass a `URLSearchParams` body to `sendBeacon`. What `Content-Type` is derived?

The browser derives the header from the runtime type of the data — no way to override it.

Answer options A text/plain;charset=UTF-8 B application/x-www-form-urlencoded C multipart/form-data; boundary=… D application/json

string → text/plain;charset=UTF-8; URLSearchParams → application/x-www-form-urlencoded; FormData → multipart/form-data with boundary; Blob uses its own type. There is no headers parameter to override any of this.

Review this lesson

Question 3 of 6

What determines whether a beacon request runs in `no-cors` or `cors` mode?

Safelisted types ride no-cors. One famous type switches the mode and triggers preflight.

Answer options A The page's CSP directive B Whether the data type's derived Content-Type is on the CORS-safelist C The request's destination URL scheme D A per-site permission stored in the browser

text/plain, application/x-www-form-urlencoded, and multipart/form-data are CORS-safelisted → no-cors mode. A Blob typed application/json derives a non-safelisted Content-Type → cors mode → preflight → the server must answer it or the beacon dies silently.

Review this lesson

Question 4 of 6

Per the specification, sendBeacon(url, new Blob([json], { type: 'application/json' })) does what?

The processing model switches the mode — and cors mode requires a preflight first.

Answer options A Sends the JSON — after a CORS preflight the server must answer B Returns false silently C Throws TypeError — the spec rejects non-safelisted Blob types D Strips the Content-Type and sends text/plain

The Blob's non-safelisted Content-Type flips the request into cors mode, so the browser issues a CORS preflight the server must answer — otherwise the beacon is dropped silently, with the boolean still true. (Some engines have at times thrown instead; that is engine behavior, not spec text.) The robust fix: send JSON as a text/plain string and parse server-side, or use URLSearchParams.

Review this lesson

Question 5 of 6

The `text/plain` JSON workaround works because…

The mode switch is the whole trap — the workaround just refuses to trigger it.

Answer options A text/plain bypasses the quota accounting B text/plain is CORS-safelisted, so the request stays in no-cors mode with no preflight C Chrome special-cases JSON strings inside text/plain D the server ignores Content-Type for POST bodies

A plain string derives text/plain;charset=UTF-8 (safelisted) → no-cors → no preflight → no CORS failure. The server reads the body, parses the JSON it contains, and everyone goes home happy.

Review this lesson

Question 6 of 6

What does the CORS-safe builder recipe produce?

It is the client-side half of the CORS story — the server half is the collector page.

Answer options A A FormData that Chrome accepts without throwing B A payload builder that keeps every derived Content-Type on the CORS safelist C A URL encoder that fits payloads under 64 KiB D A header builder for the three required CORS response headers

The builder wraps JSON into text/plain strings, uses URLSearchParams for form data, and Blob with safelisted types only — guaranteeing the auto-derived Content-Type never flips the request into cors mode.

Review this lesson

Test your knowledge: Data Types & the CORS Trap