What Webflow says officially
Webflow’s Terms of Service include a specific HIPAA section. The terms say the platform may not meet HIPAA requirements and prohibit customers from providing or enabling end users to provide PHI through website content or use of the platform. Webflow summarizes the rule by saying it does not offer HIPAA services.
The Acceptable Use Policy independently prohibits collecting, storing, or processing PHI and other protected health data. Webflow’s privacy FAQs discuss general privacy obligations but do not replace those express platform restrictions.
This is a clear “no” for PHI processing. It does not prevent a healthcare organization from publishing public information, provided the Webflow account and site remain outside the patient-data flow.
What this means for a medical practice
A brochure website can show services, locations, biographies, articles, and phone numbers without receiving patient information. Risk begins when a contact form asks why a patient needs care, an upload accepts a referral, a member area contains records, or a CMS entry includes a testimonial or case detail that identifies someone.
Context matters. A name and email submitted from a treatment-specific landing page may reveal a healthcare relationship. Webflow form storage, notification emails, automation, analytics, and scripts can make additional copies even if the visible question looks generic.
A HIPAAconscious medical website should use a separately approved intake service and keep tracking away from the protected handoff. A disciplined healthcare website redesign can preserve Webflow for public content while deleting old forms and integrations that invite health details.
Staff operations also need a boundary. Do not paste patient messages into Webflow support, CMS items, designer comments, or project backups. If a visitor sends health details through a public channel despite instructions, the practice needs an incident and redirection procedure.
Removing a form is not enough when old collection paths survive in cloned pages, staging domains, archived projects, or automation history. Inventory every published and unpublished Webflow project owned by the practice. Search form names, CMS fields, uploaded assets, exports, and integration dashboards for prior patient information, then handle any discovery under the practice’s incident and retention procedures.
Developers and agencies need the same rule in their statement of work. They should build and test with fictional information, receive only the minimum account access, and avoid copying production data into screenshots or bug reports. When a protected external form is embedded or linked, test that Webflow’s analytics and scripts cannot read its answers.
Compliant alternatives
Wix offers a documented PHI-protection mode and BAA on supported plans, with incompatible apps restricted. Jotform offers a focused form environment and BAA on eligible plans, which can be linked from a public Webflow site while keeping Webflow itself free of PHI.
That split architecture must be tested: the public page, analytics, URL parameters, and notification tools should not receive the protected submission on its way to the separate provider.
Bottom line
Do not collect, store, or process PHI in Webflow. Its current terms and Acceptable Use Policy explicitly prohibit that use. Keep the platform informational or hand patients to a separately contracted service without copying their information back into Webflow.
