GDPR and web forms: what EU hosting actually changes

The short version, and a disclaimer

This is a practical explainer, not legal advice. GDPR is a real regulation with real penalties, and if you're collecting anything sensitive, personal to a large user base, or from minors, talk to someone qualified about your specific case. What follows is what actually changes for a typical form, at the level a founder or a small team needs to reason about it day to day.

Why forms are a GDPR pressure point

A web form is often the single most direct way personal data enters your systems. Name, email, sometimes an address or a phone number, sometimes something more sensitive depending on what you're asking. Unlike data your product generates on its own, a form asks a person to type it in directly, so it's an obvious first place to think about compliance rather than an afterthought.

The core GDPR ideas that apply to forms aren't exotic:

• Data minimisation: only ask for what you need. A newsletter signup needs an email address, not a phone number and a job title "just in case."
• Consent: if you're collecting data for something beyond fulfilling the immediate request (marketing emails, sharing with a third party), say so, and get an actual opt-in rather than a pre-checked box.
• Retention: decide how long you're keeping responses before you collect them, not after someone asks you to delete their data.
• The right to access and delete: someone can ask what you have on them and ask you to remove it, and you need a way to actually do both.

None of this is unique to forms, it's the same handful of principles that apply to any system holding personal data. Forms just make the moment of collection visible and easy to get wrong, because it's tempting to add "just one more field" without asking whether you'll actually use it.

Consent wording that actually works

Vague consent language creates risk without buying you anything. "By submitting this form you agree to our terms" bundled with three unrelated uses of the data is the kind of thing that looks like consent but probably isn't, because it isn't specific. Better: separate checkboxes for separate purposes. "Email me updates about this event" is one checkbox. "Add me to the monthly newsletter" is a different one. If someone only wants the first, don't make them accept the second to get it.

Keep required fields to what the form's stated purpose actually needs, and keep any marketing opt-in unchecked by default and clearly separate from the fields required to submit.

Where the data lives

This is the part hosting location actually addresses. YeetForm is hosted on Hetzner infrastructure in Germany, and the form responses YeetForm stores stay in the EU. One honest footnote: the AI features (generating, translating, analysing) call Anthropic's API, so the text you send through those features is processed by Anthropic under its own data terms. Collecting and storing responses does not involve the AI at all. If your business or your users are in the EU, that removes a specific, real concern: international data transfer rules, and the paperwork (standard contractual clauses, transfer impact assessments) that comes with moving personal data to a processor outside the EU or an adequacy-approved country.

That matters, but it's one box on a longer checklist, not the whole checklist. Where your data sits doesn't decide whether your consent wording is specific enough, whether you're keeping responses longer than you told people you would, or whether you've actually got a process for deleting someone's data on request. Hosting location is infrastructure. Consent, minimisation, and retention are decisions you make regardless of which country the servers are in.

What a processor is, and why it matters here

Under GDPR, when you collect data through YeetForm, you (or your organisation) are the data controller, deciding why the data is collected. YeetForm is a data processor, handling that data on your behalf, under your instructions. That distinction determines who's responsible for what: you decide what to ask and why, we're responsible for the infrastructure holding it. That's the standard controller-processor relationship in this kind of tool, and it's why the hosting location and security of the processor still matters even though the compliance decisions (what to collect, what consent to ask for) sit with the controller.

Exporting and deleting

Two GDPR rights come up constantly with forms: someone asking what data you hold on them, and someone asking you to delete it. Practically, that means you need to be able to find one person's response among everyone else's, hand it over or remove it, and not have a copy lingering somewhere you forgot about.

Response data is exportable as CSV from the dashboard, so pulling one person's answers to answer an access request is a filter-and-export, not a database query you have to write. Deleting a form or a response removes it from YeetForm's systems. If you're additionally piping every response into a spreadsheet via Google Sheets or into other tools through Zapier, Make or n8n, remember that a deletion request now needs to reach those downstream copies too. That's true of any integration with any tool, not specific to YeetForm, but it's easy to forget the copy sitting in a spreadsheet three clicks away from where you first thought to look.

Retention: decide it up front

Set a retention period before you need one. "We keep event registration data for 90 days after the event" is a policy you can write in one sentence and actually follow. "We'll figure out deletion when someone asks" is not a policy, it's a promise to do the work under time pressure, for every person who asks, indefinitely. If your form collects something you don't need six months from now, plan to delete it at that point rather than let it accumulate as a growing pile of exposure with no upside.

Hosting location is one part of it

It's worth saying plainly: choosing an EU-hosted tool is a real, useful step, and it's not the same as being GDPR compliant. Compliance is mostly about what you ask for, what you tell people you're doing with it, how long you keep it, and whether you can act on an access or deletion request when one arrives. A form builder can make the infrastructure side straightforward. It can't decide your consent wording for you, and it can't make a form's list of fields shorter than you chose to make it.

For a deeper walkthrough of building a form with this in mind from the start, field by field, see the GDPR-compliant forms guide. More on where and how YeetForm is built is on the about page.

Start with the fields you actually need, write the consent checkbox in one honest sentence, and you're most of the way there.