Streaming live at 10am (PST)

How Webflow handles visitor traffic and form submissions for published websites

With GDPR dominating the airwaves (and your inboxes) lately, we’ve been getting more questions around how Webflow handles site visitors and form submissions for websites running on Webflow Hosting. I wanted to address some of those concerns here.

First, in regards to general website traffic:

  • As requests come in, our servers record hashed IP address in memory only for up to 24 hours in order to prevent against brute-force attacks (that is, to prevent one computer sending thousands of request to one page per second from crashing our service for all other visitors).

  • These hashed IPs are also used to “guesstimate” how many unique visitors a site receives (using an algorithm called HyperLogLog), without actually needing to store the addresses. The output of this algorithm is a single number (not a database of requests) and is only used to display the “Unique Visits” statistic on a Webflow project’s dashboard (under General > Site Statistics > Unique Visits).

  • Full IP addresses (or any other information that can trace back to a person’s identity) for any hosted site visitor are never stored on disk or in our logs. When we do need to record access and error logs where something like an IP address is useful (for example, to tell which edge server across the world should serve a request), we anonymize the address by removing the last octet. For example, if my IP address is and the request is temporarily logged, 157.130.212._ is written to the logs instead. While you can get some information from this type of address (for example, the country or city of the visitor), it doesn’t contain enough detail to be associated with an individual internet connection or physical address.

    • When we work with partners like Fastly for speeding up our websites, we make sure to configure our integrations in a way that full IP addresses are never logged.
  • We don’t share or sell any data around user requests or visits, period. We believe doing so would be a breach of customer trust. We would only add any kind of analysis or reporting by customer demand (for example, for a future more robust traffic dashboard), and even in those cases we would bias heavily towards avoiding any processing of personal information.

As a follow up to that, here’s what we do with adding cookies on published sites:

  • We absolutely don’t add any tracking, analytics, or any other kinds of cookies to published sites by default.

  • If you choose to enable Google Analytics for your site, or Typekit, or widgets like the Facebook Like button, then those particular components might add 3rd party scripts or cookies that are outside of our control.

  • If you add custom code that pulls in 3rd party scripts, those scripts may add cookies to your site. But these are all under your control as the site owner, and Webflow is not adding anything behind the scenes to track your users.

  • If you use the Editor via the ?edit shortcut, we do set a first-party session cookie in order to facilitate login to the editor, without which logging in would be impossible. This only applies to the site owner and collaborators who know about that URL, and this cookie is not set for actual page visitors.

If you’re also adding forms to your websites, and processing form submissions with Webflow, here’s how we handle that data:

  • Form submissions are sent securely from a site visitor’s browser to Webflow’s servers over HTTPS

  • Our database servers are hosted on the Amazon Web Services cloud within the United States

  • All of our database servers are isolated from the public internet via Amazon’s Virtual Private Cloud, and access to our servers is controlled under strict security protocols

  • All form submission data is stored in an encrypted database.

  • Webflow is certified under the Privacy Shield program, which creates a legal framework for transferring the data of EU/Swiss subjects outside of Europe. We provide more detail about this in the International Transfers section of our EU & Swiss Privacy Policy.

  • We store the IP address associated with that form submission to prevent brute-force submissions (and soon, when we release reCAPTCHA functionality for forms, the IP address will be used to prevent against certain types of CAPTCHA-circumvention attacks by spammers). We’re currently investigating whether it makes sense to place a shorter retention policy on these addresses.

  • Webflow staff does not have direct access to form submission data, and it’s automatically removed for debugging operations (for example, when a customer asks our support team to investigate a bug on one of their sites and we clone that site for analysis, the cloned site does not contain any visitor or form submission data). There are strong access control and security policies in place that prevent access to this data.

  • We only make form submission data available to the site owner so that they can use it for the purpose for which it was collected.

    • We ask all site owners to follow certain rules for handling end user data for which they are the data controller.
    • We’re also implementing a feature to allow site owners to hide their own access to form submission data in the case where they are not the true Data Controller for the form submission data. This feature will still have some flexibility to see form data during the testing/development of a site (that is, when you’d typically send test submissions to make sure everything works), and revoke it once a site is handed over to a client.
  • We absolutely do not share, pass on, analyze, or sell any form submission data to any other parties. We believe this would be a fundamental breach of the trust you place in us as a website hosting and management platform.

  • We offer the flexibility to completely skip submitting to Webflow’s servers by setting a custom action for forms built in Webflow.

In a nutshell– while some other companies out there would jump at the chance to analyze, share, and potentially sell the high volume of visitor data, we have no desire or intention to do so. We believe that going in that direction would compromise the trust that our customers and this community has placed in us as a robust and dependable web design platform.

Please let me know if there are any follow up questions that I can answer - I’ll be around! :slight_smile:


Hi @callmevlad

Thanks for the detailed information, I have a question regarding forms…

Part of the GDPR covers requesting that a company delete the data they hold about you. Can you make it possible for us to delete the form data on an individual basis in the ‘forms’ tab of the project settings page?

Yes, we’re working on this - no timeline yet though. In the meantime, if you do get a data deletion request, you can get in touch with us (within the 30 day window) and we can delete it via an automated internal script.

1 Like

Awesome - good to know.

No other questions yet…maybe you’ve cleared everything up…
or maybe people are still reading :wink:

1 Like

Hey, reading up on the terms and would like to know what the license part actually mean in this statement.


We may allow you to post, publish, or upload content to our Service. If you do this, you will own your content, but we get a license to anything you upload to the Service. Any feedback sent to Webflow is owned by Webflow and can be used or distributed by Webflow in any manner and without cost.

Thats awesome News. Thanks for getting clear on this topic. Two questions left: is this statement anywhere available outside the Forum? Something more official…
And are there plans for the jQuery third Party request? Actually we are forced to use this third party cdn.


@jorn I’m clarifying with our attorneys what that means exactly so that I could let you know in more detail. As I understand it, this allows us to use uploaded images/content to publicly advertise Webflow sites and work created with it (for example, – but it’s certainly not clear how it applies to private projects (e.g. uploads to the Asset Manager for a site). That entire section is more around the public nature of profiles and sites on our Discover section - I’ll be working with our team to make sure that’s clarified.

@Christoph_Schober Yeah, we are working on moving it to our help center documentation - stay tuned!

Re: jQuery, we don’t have immediate plans to swap out the URL, but can you let us know more about your needs in a separate thread or via the Wishlist?

1 Like

Awesome Vlad, it makes sense what you described.

To piggyback on Vlad’s comments, you see a very similar thing in the terms of service of any platform that allows people to publish content.

See, for example, this passage from Medium’s terms:

You own the rights to the content you create and post on Medium. By posting content to Medium, you give us a nonexclusive license to publish it on Medium Services, including anything reasonably related to publishing it (like storing, displaying, reformatting, and distributing it).

My understanding is that the license is required to even enable said publishing.

In my spare time, I write and publish poetry and short stories, and every journal I’ve submitted to asks for equivalent rights.

1 Like

Thanks John, yes it makes perfect sense =)

1 Like

Thanks for the info again Vlad,
@jQuery: Wishlist… nah… this is legal topic not a feature request for the wishlist or a personal wish. gets Visitors IP’s and i have no chance to prevent that. Also there is no information on jquery foundation site if and how they use the data. So please don’t let the whole thing leak on this little last topic.


Awesome thanks @callmevlad!
Is this statement being published into a page on the website or are we allowed to create a PDF of the notice to use as a link for visitors regarding GDPR in Privacy Policy’s?

Many Thanks

Awesome - good to know.