Webflow's terms forbid collecting health data. Framer's do not mention it
Section 3.6 of Webflow's terms is a contractual undertaking not to collect Protected Health Information, not a note about a missing feature. Framer's terms do not mention HIPAA at all. Here is what each means for a healthcare form.
Webflow's terms of service contain a clause that most people building healthcare sites on Webflow have never read. Section 3.6 is headed HIPAA Non-Compliance, and it does not say the platform lacks a feature. It says you agree not to collect the data.
The wording, read on 16 September 2026, is that you acknowledge the Platform may not be compliant with HIPAA and you agree not to provide or enable End Users to provide Protected Health Information in the Website Content or otherwise in connection with your use of the Platform. Webflow then restates it in its own plain-English gloss: please do not collect Protected Health Information using the Platform, as Webflow does not offer HIPAA compliant services at the present time.
That is a contractual undertaking, not a capability note. A native Webflow form collecting a care enquiry with a health detail in it is a breach of the agreement the site owner accepted, independently of anything HIPAA itself says. It is a cleaner fact than the usual discussion, because it does not require deciding whether your enquiry form collects PHI in the legal sense. The terms tell you what to do either way.
What Framer's terms say about it
Nothing. We searched Framer's terms of service on the same day and the words HIPAA and Protected Health Information do not appear anywhere in the document. That is worth stating carefully, because silence is not permission. It means there is no prohibition to breach and also no commitment to rely on, and a buyer in a regulated sector has nothing to read either way.
Between an explicit prohibition and no mention at all, the explicit prohibition is the more useful document. It tells you exactly where the line is, which lets you design around it in an afternoon. Silence has to be resolved by asking, and on a platform with no BAA on offer the answer to that question is usually the same anyway.
So where does the form go
Off the platform. The pattern that works is an embedded form from a vendor that will sign a business associate agreement, so the regulated data never touches the site builder's own form handling. Jotform states that the Gold or Enterprise plan gives access to HIPAA-enabled features and that customers who enable those features receive a signed BAA. Formstack offers a BAA on its enterprise tier. The specific vendor matters less than the two questions to ask before choosing one.
- Which plan does the BAA sit on. It is almost never the entry tier, and a quote built on the cheapest plan will be wrong by the time the agreement is signed.
- Where does the submission go afterwards. A BAA on the form vendor covers the form. It does not cover the notification email, the CRM the lead lands in, or the spreadsheet somebody exports it to, and those are where regulated data usually ends up.
- Does the embed leak. A form that posts to the vendor but also fires an analytics event carrying the field values has moved the data back onto the page, which is the failure we see most often.
The scoping side of this, including what counts as the combination that creates the obligation in the first place, is in what makes a contact form a HIPAA problem and can a Webflow site be HIPAA compliant. This post is the narrower point: before any of that analysis, the platform's own contract may already have answered the question.
