Build or import
Choose the method and URL, add query params, auth, headers, and a body, or import an existing cURL command.
Requests beside the response
Build and inspect HTTP requests without changing tools
Compose a request with params, authorization, headers, and several body modes; import cURL; use local environments; save useful requests; and inspect response body, headers, cookies, raw output, status, size, and timing in one workspace.
- Import cURL
- Local environments
- Saved requests
- Response inspection
Request flow
Compose, send, inspect, reuse
Send deliberately
Set a timeout, inspect the resolved URL and environment values, then press Send. Network activity begins only after that action.
Inspect and save
Review the body, headers, cookies, and raw response; save the request or copy it as cURL, fetch(), or PowerShell.
Example
Turn a simple GET into a reproducible request
The client keeps structured controls and copyable code aligned so you can move between interactive debugging and a script.
Request
GET with a query parameter
Environment variables can replace stable values while the resolved URL stays visible before sending.
Method: GET
URL: {{baseUrl}}/v1/products
Params:
view = summary
Headers:
Accept = application/json
Timeout:
30000 msCopy as fetch
Carry the verified request into code
Generated snippets reflect the active method, resolved URL, headers, auth, and body choices.
const response = await fetch(
"https://api.example.com/v1/products?view=summary",
{
method: "GET",
headers: {
Accept: "application/json"
}
}
);
const data = await response.json();
Hands-on tutorial
Build, send, inspect, and preserve one API request
Use an API you are authorized to call. The example uses a development base URL and a products route; replace those values with your own service while keeping the same learning sequence.
-
Open HTTP Client and choose the environment first
Launch HTTP Client from General tools, the extension launcher, or the Windows Tools menu. Create or select a development environment and add
baseUrlwith a value such ashttps://api.example.com. Use a non-secret variable first so you can see how resolution works safely. -
Compose the URL from stable and changing parts
Choose GET and enter
{{baseUrl}}/v1/products. Add a query parameter namedviewwith valuesummary. Inspect the resolved URL before sending; a missing or misspelled variable should be fixed now, not diagnosed after a network error. -
State what representation you expect
Add
Accept: application/json. Leave authorization and body set to None for this lesson unless your endpoint requires them. Set a practical timeout such as 30,000 ms so a stalled request does not remain active indefinitely. -
Send deliberately and observe the transition
Review method, resolved URL, params, and headers, then press Send. This is the point where network activity begins. The action changes to Cancel while active; editing the request, importing cURL, or generating a snippet does not send anything.
-
Read status and metadata before the body
Start with the status code, duration, size, and content type. A 200 JSON response supports the Body workflow below. A redirect, 401, 404, 415, or HTML content type changes the question you should ask before inspecting individual fields.
-
Compare formatted Body, Raw, and Headers
Use Body to understand structured JSON, Raw to verify the exact response text, and Headers to inspect caching, content type, dates, rate limits, and server behavior. Check Cookies only when the response actually uses them and your product’s browser policy exposes them.
-
Copy a reproducible handoff and save only what is useful
Copy the verified request as cURL,
fetch(), or PowerShell and review it for credentials before running or sharing it. Save the request or add it to a collection when it is worth repeating. Give it a name that describes the behavior being tested, not simply “GET request.”
Practice: turn the GET into a controlled JSON POST
Duplicate the request instead of overwriting your working GET. Change one concern at a time and inspect the generated snippet after each change.
- Change the method to POST and select the JSON body mode.
- Add a small valid JSON object and verify its syntax.
- Confirm
Content-Type: application/jsonis present. - Add authorization only if your own endpoint requires it.
- Send to a development or test endpoint you control.
- Review status, response content type, and Raw before trusting Body.
Response inspection
The body is only one part of the answer
Status, content type, response headers, cookies, timing, and the raw response can explain behavior that a formatted JSON body cannot. Compare these views when investigating caching, authentication, redirects, content negotiation, compressed responses, or a server that returns useful diagnostics outside the body.
Response lesson
Let the status, headers, and timing choose the next question
A formatted body is useful only after you know what kind of response you received. Use this order to avoid debugging application data when the real problem is authentication, routing, media type, browser policy, or server availability.
| Signal | Investigate next | Useful evidence to capture |
|---|---|---|
| 200–299 success | Confirm content type, body shape, headers, and whether the response matches the requested representation. | Status, response body, relevant headers, and duration. |
| 301, 302, 307, or 308 redirect | Inspect the final URL and redirect behavior; confirm the method was preserved where required. | Location-related headers, final response, and copied request. |
| 401 or 403 | Check auth type, token value, API-key placement, scopes, environment selection, and target host. | Sanitized request details and response authentication headers—never the secret itself. |
| 404 | Check the resolved base URL, route version, path variables, and whether the resource exists in this environment. | Resolved URL, method, and response body. |
| 400 or 415 | Review JSON syntax, body mode, Content-Type, required fields, and encoding. | Sanitized body, request headers, and server validation message. |
| 429 | Inspect rate-limit and retry headers, then reduce or delay requests. | Limit, remaining, reset, and retry values. |
| 500–599 | Separate a reproducible client request from a server-side failure. | Request ID, timestamp, status, duration, and sanitized request snippet. |
| CORS or browser network failure | Compare with generated cURL or PowerShell outside the browser. The extension cannot bypass the target server’s CORS policy. | Browser error, target origin, method, and server CORS configuration. |
A variable remains unresolved
Confirm the active environment, exact variable spelling, and braces. Resolve the URL before adding authentication or body complexity.
Body view is empty or unreadable
Check status, content type, size, and Raw. A HEAD response, empty success, binary payload, or HTML error page may not have a formatted JSON body.
The same call works in cURL but not the extension
Compare generated commands and then inspect CORS, browser credential policy, cookies, redirects, and headers the browser is allowed to expose.
The request contains sensitive values
Avoid screenshots and exports that expose credentials. History is sanitized, but saved environments and requests remain local profile data rather than a separate encrypted secrets vault.
Learning outcome: you should be able to preserve one reproducible request, explain when network activity occurs, and diagnose a failure from status and metadata before guessing at the body.
Capabilities
Enough request control for daily API investigation
Methods and URLs
- Common HTTP methods
- Query parameter editor
- Resolved environment preview
- URL validation
Authorization
- Bearer token
- Basic authentication
- API key presets
- Custom headers
Request bodies
- Raw text and JSON
- Form URL encoded
- Multipart form data
- GraphQL
Response views
- Formatted body
- Headers
- Cookies
- Raw response
Reuse
- Saved requests
- Local environments
- Import and export JSON
- Import cURL and copy snippets
Control and feedback
- Timeout and cancel
- Status, type, and size
- Timing breakdown
- CORS and network error guidance
Privacy and storage
Know what leaves the device
Explicit network action
The client contacts the URL displayed in the composer only after you press Send. The destination service receives the request directly.
Local saved data
Saved requests, environments, and replay history are stored locally. Protect the browser profile if those values contain secrets.
Sanitized history
Replay history omits request bodies, credential headers, URL credentials, and sensitive query parameters.
Local storage is not separate secret encryption.
Use environment values carefully, avoid saving credentials you do not need, and review the target service’s policy before sending sensitive data.
FAQ
HTTP Client questions
Can the browser extension bypass CORS?
No. The target server’s CORS policy still determines whether the response is exposed to the browser. CodePrettify reports likely CORS failures with targeted guidance.
When is a request sent?
Only when you press Send. Editing the URL, importing cURL, changing an environment, or copying a snippet does not send the request.
Are saved secrets encrypted separately?
No. Protect your browser or Windows profile and avoid persisting sensitive values unnecessarily.
Can I move a request into a script?
Yes. Copy the active request as cURL, JavaScript fetch(), or PowerShell and review the generated command before running it.
Related guides
Inspect what the API returns
Keep the request and response in one workspace
Compose the call, inspect more than the body, and copy a reproducible request when the investigation is complete.