Why a form in a shared static HTML preview does not submit

A form drawn in HTML is not a form backend. It can collect values in the browser, but submission needs an authorized endpoint that validates, stores, and processes those values. HTML2WEB previews intentionally block form navigation and network connections, so a shared mockup cannot silently transmit visitor data.

Identify what you are testing

Goal	A static preview can do it?	What is still required
Review labels and layout	Yes	No backend
Check client-side validation	Usually, with inline JavaScript	Test data only
Send a real enquiry	No in the HTML2WEB viewer	Approved receiving service and privacy flow
Test production integration	Not from the isolated preview	A controlled staging environment

MDN’s form guide explains that form data is sent to a server. An action attribute names a destination; it does not create that destination.

Why common approaches fail

The form has no action

The browser has nowhere meaningful to send the data. Add a visible demonstration state for a mockup instead of pretending the enquiry was delivered.

JavaScript calls an API

The target must exist, allow the request origin, accept the method and headers, validate the data, and return an appropriate response. CORS is the server’s browser-access policy, not a switch the HTML author can override.

The preview blocks the request

HTML2WEB runs untrusted documents inside a sandbox. Its content security policy currently uses connect-src 'none' and form-action 'none'. Inline interactions can run, but shared code cannot post data or fetch arbitrary services from the viewer.

A secret key is embedded

Anything inside browser HTML is available to the viewer. Never embed an API key, private webhook secret, SMTP password, or database credential to make a demo submit.

Make the mockup honest

Use sample data and one of these patterns:

• intercept submit and show “Demo only—no data was sent”;
• disable the submit control with a clear staging label;
• render success, error, and validation states using local fixture data;
• link reviewers to a separate, approved staging environment for integration tests.

Do not collect real names, emails, phone numbers, or messages in a mockup that cannot protect or delete them.

Move to production deliberately

When the design is approved, implement the real flow in its owning application:

1. minimize fields and publish a clear privacy notice;
2. validate on the server;
3. add abuse and rate controls;
4. store or queue the enquiry durably;
5. authenticate email sending;
6. trace accepted requests to notifications or CRM records;
7. display success only after the promised acceptance state.

Use the HTML-to-URL tool to review the interface, not to host a production lead-capture backend. If other JavaScript behaves differently after sharing, read the sandbox and CORS boundary guide.