Form Action URL Tester — is your endpoint reachable?
Paste any form action URL and the tester runs a safe HEAD + OPTIONS probe from your browser: HTTP status, CORS headers, POST-acceptance, response time, and detected backend (splitforms, Formspree, Web3Forms, mailto:, localhost). Never POSTs to the URL. Nothing stored.
Sends a HEAD + OPTIONS probe from your browser. Never POSTs. Nothing is logged or stored.
How this works
When you paste a URL, the tester runs three checks. First, a HEAD request with mode: "no-cors" to see if the host is reachable at all — that catches DNS failures, dead domains, and offline servers. Second, an OPTIONS preflight requestto ask the server if it accepts cross-origin POST — that's how browsers verify real form submissions before they fire. Third, a service-detection pattern match against known form backends so you get a useful label instead of a raw URL.
We never automatically POSTto the URL. POSTing would submit a real form to whatever backend you're testing — triggering an email notification, a webhook, or a database insert you didn't ask for. The tester is read-only: HEAD and OPTIONS are safe methods that no well-built backend treats as data-bearing.
For mailto: URLs we skip the network entirely. We parse the URL with the built-in URL constructor, extract the email address, and warn you that mailto: forms are unreliable, leak your email, and have zero spam filtering. About half the visitors on a typical contact page never complete a mailto: submission because clicking the button opens a desktop mail client they don't use.
CORS-blocked responses are normal for cross-origin requests and don't mean the endpoint is broken — they just mean JavaScript on splitforms.com isn't allowed to read the response from another origin. The browser still delivered the request successfully. The tester reports exactly what JavaScript is allowed to see, which sometimes underrepresents what really happened. To verify a POST end-to-end, use curl from your terminal.
Localhost and private IPs (127.0.0.1, 10.x, 192.168.x, 172.16-31.x) get a yellow warning. They work in dev but won't be reachable from your visitors' browsers in production. Catching that mistake before deploy is the single most common reason developers use this tool.
Why use a real form backend
Most of the form-action URLs we see on this tester fall into three buckets: mailto: addresses (don't use them), competitor backends (Formspree, Web3Forms, Getform — see comparisons below), and custom server endpoints (often localhost in dev, often broken CORS in prod). A managed form backend eliminates all three failure modes.
- Why is my contact form not submitting? — debugging guide for broken action URLs
- Honeypot vs reCAPTCHA — pick the right anti-spam layer
- splitforms vs alternatives — head-to-head comparisons
- splitforms quickstart — point any HTML form at our endpoint, get submissions in under 60 seconds
Form action tester FAQ
What does this form action URL tester actually check?
Six things, all from your browser. Reachability — does a HEAD request to the URL get a response at all (or does it fail with a network error). HTTP status code — 2xx, 3xx, 4xx, 5xx, or opaque. Rough response time in milliseconds (start of request to first response). CORS headers when readable — Access-Control-Allow-Origin and Access-Control-Allow-Methods, which determine whether browser-side JS can read the response. Detected service — splitforms, Formspree, Web3Forms, Netlify Forms, mailto:, localhost, or unknown. Whether the URL accepts POST via an OPTIONS preflight. We never automatically POST to the URL because that could submit a real form to the backend.
Why does the tool say 'CORS-blocked' or 'opaque' for some URLs?
Browsers enforce the same-origin policy. When you fetch a third-party URL from splitforms.com without the right CORS headers, the browser hides the response body and headers from JavaScript — what you get back is an 'opaque' response. That doesn't mean the URL is broken. It means the server didn't set Access-Control-Allow-Origin to allow our origin. For a form backend that's perfectly normal — the browser still successfully delivered the request, you just can't read the response from another origin. Look at the network tab in DevTools to see the real status; this tool reports what JS is allowed to see.
Does the tool actually submit my form?
No. We send HEAD or OPTIONS requests only. HEAD asks 'are you there, what are your headers' without a request body. OPTIONS is the CORS preflight method browsers use to ask 'do you accept POST from this origin'. Neither method delivers form data. We deliberately do not POST because doing so would submit a real form to your backend and trigger an email notification, a webhook, or a database row. If you want to verify a POST actually goes through, do it manually with curl or with the splitforms dashboard test feature.
What's wrong with mailto: form actions?
Three problems. Reliability — mailto: depends on the visitor having a configured email client. Roughly half the visitors on a contact page don't (mobile especially). Privacy — mailto: leaks your email address into your HTML, where scrapers harvest it for spam lists. Spam filtering — there isn't any. Every bot submission lands directly in your inbox. mailto: forms also can't be styled, can't have webhooks, can't store submissions for follow-up, and can't trigger any automation. Use a real form backend (splitforms is free for 1,000/month) and keep mailto: links for raw email addresses, not form submissions.
What does 'service detected: splitforms' mean?
We pattern-match the URL against known form-backend hostnames. If the action points at splitforms.com/api/submit the tester confirms that with a 'looks good' verdict. If it points at formspree.io, web3forms.com, getform.io, formcarry.com, formspark.io, formkeep.com, formbold.com, basin.com, or staticforms.xyz we identify the competitor and link to the corresponding /vs/ comparison page. If it points at localhost, 127.0.0.1, or a private IP we flag it as local-dev (won't work in production). Unknown URLs get a neutral 'custom backend' label.
Is anything stored or logged?
No. The tester runs entirely in your browser. The URL you paste is never sent to splitforms — only to the URL itself, by your browser, exactly the same way the original <form> would. We don't collect logs, store inputs, or fingerprint requests. Open DevTools and watch the Network tab if you want to confirm: there's no request to splitforms.com when you click test, only to whatever URL you entered.
Why doesn't the OPTIONS preflight work for my custom backend?
Three common reasons. Your server doesn't handle OPTIONS — many small backends only implement POST and return 405 Method Not Allowed for OPTIONS. Your server returns OPTIONS but doesn't include the CORS headers the browser expects, so the response is opaque. Your server is behind Cloudflare or another WAF that rate-limits or blocks unusual methods. None of these mean your endpoint is broken for the actual form submission — they just mean the browser-side preflight check is inconclusive. To definitively test POST behavior, use curl: curl -X POST https://your-endpoint -d 'name=test'.
Skip the dead URL. Use a backend that works.
splitforms is a free form backend for developers — drop one POST endpoint into any HTML form, get submissions in your inbox with honeypot + AI spam filtering, webhooks, and a real dashboard. 1,000 submissions per month, free forever.
Try splitforms free →