도구 가이드
developer 무료 회원가입 불필요

웹훅 / HTTP 요청 테스터

브라우저에서 HTTP 요청을 구성하고 전송하여 응답을 자세히 검사합니다.

도구를 불러오는 중…

이 도구에 대해

HTTP 요청을 구성하세요 — 방법을 선택하고 URL을 입력하며 사전 설정 바로 가기로 사용자 정의 헤더를 추가하고 요청 본문을 작성 — 그런 다음 전송 버튼으로 실행하세요. 응답 패널에는 상태 코드, 응답 헤더 및 응답이 JSON인 경우 예쁘게 인쇄된 본문이 표시됩니다. 응답 시간은 밀리초로 측정되며 마지막 다섯 개의 요청이 빠른 재실행을 위해 localStorage에 저장됩니다.

사용 방법

  1. 1 HTTP 방법(GET, POST, PUT, PATCH, DELETE)을 선택하고 대상 URL을 입력하세요.
  2. 2 키-값 편집기를 사용하여 필요한 헤더를 추가하세요; 일반적인 헤더에는 사전 설정을 사용하세요.
  3. 3 POST/PUT/PATCH 요청의 경우 본문을 입력하고 Content-Type을 선택하세요.
  4. 4 전송을 클릭하고 응답 패널에서 상태 코드, 헤더 및 본문을 검사하세요.

What this tool actually does

This is an HTTP request builder that sends a real network request from your browser and shows you the full response. You pick a method (GET, POST, PUT, PATCH, DELETE), type a URL, optionally add headers and a request body, and press Send. Under the hood it calls the browser's standard fetch() API, so the request leaves your machine and travels to the server you named — this is not a simulation, and the URL and any data you send go to that endpoint. The response status, headers, body, and round-trip time come back and are displayed, with JSON automatically pretty-printed.

The CORS reality you must understand

Because the request originates from a web page, it is governed by the browser's same-origin policy and CORS (Cross-Origin Resource Sharing) rules. When you call an API on a different domain than this site, the browser only hands you the response if that server explicitly opts in by returning an Access-Control-Allow-Origin header that permits the request. If the server does not, the browser blocks the response and you get a network/CORS error — even though the server may have received and processed the request. The tool detects this case and shows a hint that it is "likely a CORS error."

This is a browser limitation, not a bug. It means this tester works perfectly against:

  • APIs that are CORS-enabled (many public REST and testing APIs are);
  • your own server, once you add the right CORS headers;
  • any endpoint behind a proxy you control that adds CORS headers.

For testing arbitrary third-party APIs that lack CORS, a desktop client like curl or a server-side script is the right tool, because those are not bound by browser CORS.

A worked example

Select POST, enter a URL such as a CORS-friendly echo endpoint, click + Content-Type (which inserts the header Content-Type: application/json), choose the JSON body type, and paste:

{"name": "Ada", "role": "engineer"}

Press Send. The tool builds the request, sends the body, and renders the response: a coloured status badge (green for 2xx, orange for 4xx, red for 5xx), the elapsed milliseconds, a table of every response header, and the body. If the server echoes JSON back, it is reformatted with two-space indentation against a dark background so it is easy to read. The exact request — method, URL, headers, and body — is saved to a local history of your last five requests, which you can click to reload and resend.

Headers and body types

The Headers section lets you add any key/value pair, with one-tap presets for the three most common: Content-Type, Authorization (pre-filled as Bearer so you just paste your token), and Accept. The body editor appears only for methods that carry a payload (POST, PUT, PATCH) and offers three encodings:

  • JSON → sends application/json;
  • Form URL-encoded → sends application/x-www-form-urlencoded (e.g. key=value&other=data);
  • Plain Text → sends text/plain.

If you have not already set a Content-Type header yourself, the tool adds the matching one automatically based on the body type you chose. A header you set manually always wins.

Common use cases

  • Inspecting a webhook payload format. Fire a sample POST at your receiver and confirm it accepts the body shape you intend to send.
  • Checking an API quickly without opening a terminal — verify a GET returns the data you expect, or that an auth token is accepted.
  • Reading response headers such as rate-limit counters, cache directives, or content type, all laid out in a table.
  • Reproducing a request from history to compare two runs after a change.

Tips and common mistakes

  • A blank response is usually CORS, not a dead server. If you get an immediate failure on a third-party URL, the server almost certainly received the request but the browser withheld the response. Test against your own CORS-enabled endpoint to confirm your request is correct.
  • Real credentials are really sent. Anything you put in an Authorization header or body goes to the destination server over the network. Only paste tokens for endpoints you trust, and avoid production secrets in casual testing.
  • Some headers cannot be set from a browser. The fetch API forbids "unsafe" headers like Host, Origin, and User-Agent; the browser controls those. If a server needs them, use a server-side client.
  • History is local only. Your last five requests are stored in this browser's localStorage, not on any server, and you can clear them at any time. They never sync to another device.

자주 묻는 질문

{# Alpine.js — self-hosted. (The previous jsdelivr CDN tag had a stale SRI integrity hash, so the browser refused to run it and window.Alpine was never defined — silently breaking every FAQ accordion and Alpine tool.) #}