HTTP Method Tester
Find out how a URL responds to different HTTP methods. The tester sends GET, HEAD and OPTIONS from our server, shows each status code, response time and the headers that matter (Allow, CORS headers, Content-Type), and checks whether a browser page on your origin would be allowed to send POST, PUT, PATCH or DELETE by running a CORS preflight, without ever performing those methods.
- Encrypted connection
- No sign-up
- Free to use
| Request | Status | Time | Relevant response headers |
|---|
How to use HTTP Method Tester
- Enter a public URL.
- Choose which safe methods to send.
- Optionally enter your front-end origin and the method and headers it will use.
- Run the test and read the findings.
HTTP Method Tester features
Safe methods only
GET, HEAD and OPTIONS; data-changing methods are never sent.
Allow header
Shows which methods the server says it supports.
HEAD consistency
Flags HEAD responses that differ from GET or include a body.
CORS preflight
Checks origin, method and headers exactly as a browser would.
Timing
Response time for each request.
Protected
Public addresses only, no redirects followed, no bodies returned.
When to use HTTP Method Tester
- Debugging “405 Method Not Allowed” errors.
- Checking that an API answers OPTIONS correctly before a front end calls it.
- Verifying a CORS configuration from outside the browser.
- Making sure HEAD works for link checkers and caches.
HTTP Method Tester FAQ
Why are POST, PUT and DELETE not sent?
Those methods can create, change or delete data, and the URL may belong to someone else. The tester only asks about them through a CORS preflight, which is a harmless OPTIONS request. Test them on your own API with the REST API Tester.
What does the Allow header mean?
It lists the methods a resource supports. Servers must send it with 405 responses and often send it with OPTIONS, but many leave it out, which is not an error by itself.
What is a CORS preflight?
Before a cross-origin request with a method other than GET, HEAD or POST, or with custom headers, the browser sends OPTIONS with Origin, Access-Control-Request-Method and Access-Control-Request-Headers. The real request is only sent if the answer allows it.
Why does HEAD return a different status than GET?
Some frameworks do not route HEAD automatically. HEAD should behave like GET without a body; link checkers, caches and monitors use it to save bandwidth.
Are redirects followed?
No. The first response is shown, so you can see a redirect status and its Location header for each method.
Can I test internal servers?
No. Requests come from our server and only go to public addresses; localhost and private networks are blocked.
HTTP methods and how servers announce them
Every HTTP request carries a method that says what the client wants: GET to read, HEAD to read only the headers, POST to submit data, PUT and PATCH to replace or change a resource, DELETE to remove it, and OPTIONS to ask what is possible. GET, HEAD and OPTIONS are defined as safe, meaning they should not change anything on the server, which is why this tester limits itself to them.
Servers tell clients which methods a resource supports in two ways. A request with an unsupported method should get 405 Method Not Allowed with an Allow header listing the permitted ones, and an OPTIONS request may also be answered with Allow. In practice many applications answer OPTIONS with 200 and no list, or with 404, so the tester reports what it sees and explains what each result means.
HEAD deserves particular attention. It should produce exactly the same status and headers as GET, just without the body. Link checkers, download managers, monitoring services and caches use it to check a resource cheaply. When a framework only routes GET explicitly, HEAD may return 404 or 405 while the page works in the browser, which leads to confusing reports of broken links.
Browsers add their own layer for requests made by JavaScript to other origins. Before a cross-origin PUT, DELETE or a request with an Authorization header, the browser sends a preflight OPTIONS request and checks the CORS headers in the answer: the origin must be allowed, the method listed and every requested header permitted. The preflight check here reproduces those rules, so you can see which part is missing when a front end reports a CORS error.
For safety, requests are sent from our server only to public addresses, redirects are not followed, response bodies are discarded after their size is measured, and the number of tests per visitor is limited. That keeps the tool useful for checking your own sites and public APIs while preventing it from being used as a proxy or scanner.