How to v1.0, updated 2026-07-07

Forms that submit over http

A form on an https page that posts to an http URL sends the data in clear text, and browsers block insecure password submission.

A form is only as secure as where it sends its data. When a page is served over https but a form on it has an action that points to a plain http:// URL, everything the visitor types is sent over an unprotected connection in clear text, where anyone on the network path can read it. The lock in the address bar is about the page, not about where the form posts.

Why it matters

Browsers treat this as seriously as they can without breaking the web. They show a not-secure warning when the form is focused, and they block submission of a password field to an insecure target outright, so a login or sign up form simply fails. Even where the browser allows it, the data is exposed, which is a real leak for anything a person types, an email, an address, a message.

Where it hides

The insecure target can be on the form itself, in its action, or on the button that submits it, in a formaction that overrides the form. A complete check looks at both. A relative action, or one that is already https or protocol relative, is fine.

The fix

Point every form action, and any formaction on a submit button, at an https:// URL so the data is encrypted end to end. The Audit flags a form that would submit over http. This is the form-shaped cousin of mixed content, the same rule applied to where data goes rather than where resources come from.

Read next

Mixed content, http resources on an https page

When an https page loads a resource over plain http, browsers block the important ones and flag the rest.

All topics
Ask Topkay the analyst×
Ask me anything about your site. I can run Topkay's tools on your twin (the audit, page speed, headers, schema, AI access), crawl or refresh it, and generate the fixes you are missing, all from here. I read the Learn corpus too and cite both. Try a skill below.