b2KIT

HTTP Request Builder

Build and test HTTP requests with method, headers, body, and authentication options using the Fetch API.

Tested tool guide Tested browser tools Checked August 16, 2026

What HTTP Request Builder does and how it behaves

HTTP Request Builder turns a target URL, HTTP method, headers, optional authentication, and body into a request sent through the browser's Fetch API. It is useful for checking how an endpoint responds without first writing application code. The common surprise is that this is still a browser request: cross-origin policy, mixed-content rules, and browser-controlled headers apply. A request that succeeds in curl or server-side code can therefore fail here even when its URL, credentials, and payload are otherwise correct.

How the result is produced

1

Request composition

Enter the endpoint and select its method, then add the headers, authentication values, and payload required by that endpoint. The body and Content-Type header are separate parts of the request. Declaring application/json does not repair or convert malformed JSON. Fetch requests using GET or HEAD cannot carry a body, so payload testing requires a method that permits one.

2

Browser execution

Testing sends the configured request from the current browser context. The builder itself does not upload the configuration to the site's backend, but sending necessarily transmits the selected headers, credentials, and body to the target endpoint. The readable result is limited to what that endpoint returns and what the browser permits the page to access.

Good uses

  • Reproduce a failing JSON API call by entering its POST URL, Content-Type header, authentication details, and exact request body.
  • Check whether an endpoint handles alternate methods such as PUT, PATCH, or DELETE and inspect the response available to the browser.
  • Compare content negotiation behavior by repeating a request with different Accept headers or test validation by changing one body field at a time.

Limits and checks

  • A browser CORS error is not an HTTP status returned by the endpoint. CORS can prevent the page from reading a response, and a failed preflight can stop the intended request from being sent. That result does not prove the same request would fail from a server or command-line client.
  • Some headers are controlled or forbidden by the browser. In particular, values such as Host and Content-Length cannot be tested as freely as they can with lower-level HTTP clients. The browser may calculate, replace, or omit such headers regardless of what was entered.
  • The response describes one live exchange, not a permanent property of the endpoint. Authentication state, rate limits, redirects, caches, changing server data, and temporary failures can alter later results. Verify the final URL and returned status before attributing a difference solely to the request body.

Common questions

Why does the same request work in curl but fail in this builder?

The builder sends through Fetch in a web page, while curl is not governed by browser cross-origin policy. The endpoint may omit the CORS response headers needed for the page to read its response, reject an OPTIONS preflight, or be blocked as insecure mixed content. A curl success therefore does not guarantee a browser-visible success.

Can I use this as a complete server-to-server HTTP client?

No. It is appropriate for requests that a browser is allowed to issue and inspect. It cannot reproduce every low-level header, bypass CORS, or perfectly model a backend network environment. Avoid placing long-lived production secrets in browser tooling; any credential included in a sent request is delivered to the target URL.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools