REST API Client / Tester

Compose and send HTTP requests with query parameters, headers, JSON / form bodies and Basic or Bearer authentication, then inspect status, timing and pretty-printed JSON responses. Import an existing cURL command or copy the current request back out as cURL. Prefer building reusable requests step-by-step? Use the HTTP Request Builder. See also the API Tools family.
Everything runs locally in your browser. Cross-origin requests are subject to the target server’s CORS policy — see the note below if a request fails.
Paste a cURL command
Query Parameters
Headers
Body
Authorization
Options
When filled, the request URL is appended to this prefix. Useful for CORS-blocked servers.
200
Body Headers 

                                                                

                                                                

                                                                    

                                                                

                                                            


                                                            

                                                            

                                                                Why a request may fail: browsers block cross-origin reads unless the API returns
                                                                Access-Control-Allow-Origin. If the target does not permit CORS you can run a CORS proxy of your own and paste its URL
                                                                into the proxy prefix above, or use the cURL Converter to run the request from a terminal instead.
                                                                Request bodies for GET/HEAD are ignored, and a WebSocket tool lives separately at the
                                                                WebSocket Tester.
                                                            


                                                            

                                                                HTTP methods explained
                                                                
The method you pick tells the server what you want done with the URL. Here is what each of the seven verbs this tool can send means:

                                                                
GET — Fetch a resource: a web page, an image, a list of records. “Give me what is at this URL.” Read-only and safe to repeat, and it normally carries no request body (a body on a GET request, if any, is ignored).

                                                                
POST — Send new data to the server, usually to create a resource or trigger an action — submitting a form, uploading a file, starting a job. The payload travels in the request body. POST is not idempotent: sending the same POST twice can create two records.

                                                                
PUT — Replace the whole resource at the URL with what you send. The body must carry the complete new version of the resource. PUT is idempotent: repeating the same request has the same effect as sending it once.

                                                                
PATCH — Change only part of a resource. You send just the fields you want to update, e.g. {"email": "new@example.com"}, instead of the whole record. Choose PATCH when a full PUT would force you to resend fields you are not touching.

                                                                
DELETE — Remove the resource at the URL. DELETE is idempotent: deleting something that is already gone returns the same outcome (usually a 404) and does nothing twice.

                                                                
HEAD — Just like GET, but the response contains headers only — no body is sent back at all. Use HEAD to check whether a URL exists, how big a file is (Content-Length), when it was last modified (Last-Modified) or what type it is (Content-Type), without downloading the whole payload.

                                                                
OPTIONS — Ask the server which methods and options are allowed for a URL, or trigger a CORS preflight check. The response headers, such as Access-Control-Allow-Methods, list what is permitted. OPTIONS usually carries no body; browsers often send it automatically before a cross-origin POST/PUT/PATCH/DELETE.

                                                                

                                                                    Easy to mix up: HEAD vs GET — the request is identical, but HEAD returns no body. PUT vs PATCH — PUT replaces the entire resource; PATCH applies a partial update of only the fields you send.