Your contact form has three fields. Name, email, message. Clean, simple, minimal. You built it yourself or your developer did, and you are confident it collects only what it needs. But have you checked the database lately? Because behind those three visible fields, your form plugin is almost certainly storing the visitor’s IP address, their browser fingerprint, their operating system, the exact page URL they submitted from, and — if you are running Fluent Forms — their city and country, obtained by quietly sending their IP to a third-party geolocation service you never configured and probably do not know exists.
This is the data minimization problem that most WordPress site owners never discover: the form they see and the form the database records are two entirely different things. And under GDPR, every piece of that hidden data carries the same legal weight as the fields the visitor consciously filled in. CNIL fined SAF Logistics €200,000 in September 2023 for a form that collected excessive fields. The principle is clear, the enforcement is real, and the gap between what you think you collect and what you actually collect is where the violation lives.
Why you cannot minimise what you have not mapped
Here is a question most WordPress site owners never ask: what is the purpose of this form? Not “what does it do” — that is obvious, it sends you a message. But what is the legally defined processing purpose that determines which data is necessary and which is excessive?
This is not a philosophical exercise. GDPR Article 5(1)(c) requires data to be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.” But necessary in relation to what? You cannot answer that without first answering GDPR Article 5(1)(b) — the purpose limitation principle. The EDPB’s Guidelines 4/2019 state it directly: “The purpose of processing should guide the design of the processing and set processing boundaries.”
A general contact form and a sales inquiry form look nearly identical. Three or four fields, a submit button, done. But their purposes are different, and therefore their field requirements are different. A general contact form exists to receive and respond to messages — name, email, and message content are necessary, and everything else requires independent justification. A sales inquiry form exists to initiate a commercial conversation — company name and phone number become defensible because the response may require organisational context or a callback. A support request form may need an order number or account identifier.
The point is not that every form needs different fields. The point is that every form needs a defined purpose, and the fields must be justified against that specific purpose — not against a vague sense of “this might be useful.”
The fields that survive scrutiny and the ones that do not
So you have defined your purpose. Now which fields actually pass the necessity test? For a standard “Contact Us” form whose purpose is responding to email-based inquiries, the analysis is straightforward.
Name and email are necessary — one to address the response, the other to deliver it. Message content is the inquiry itself. A subject line or category dropdown aids routing and is defensible. That is your baseline. Three fields, possibly four.
Now here is where most forms go wrong. Phone number is the most common unnecessary addition, and it is the one the ICO’s guidance specifically calls out. If your form responds by email, why do you need a phone number? The answer most site owners give — “in case we want to call them” — is exactly the reasoning GDPR prohibits. The ICO is explicit: “You must not collect or retain personal data on the off-chance that it might be useful in the future.” If you genuinely offer callbacks, use conditional logic — show the phone field only when the visitor selects “please call me back.” That way you collect phone numbers only from people who actually want a call, which is data minimization through design rather than data hoarding through habit.
Company name and job title? Defensible on a B2B sales form where organisational context genuinely shapes the response. Indefensible on a general consumer contact form. And here is a conversion story that makes the compliance case better than any regulation can: Expedia discovered that an optional “Company” field on their booking form was confusing consumers into entering their bank name, causing address verification failures. Removing that single field recovered $12 million in annual revenue. The unnecessary field was not just legally questionable — it was actively destroying business.
Date of birth, gender, postal address, demographic fields? The EDPB’s Guidelines 4/2019 use a web form as their worked example and specifically identify date of birth as unjustifiable for online purchases. If it fails the necessity test for buying a book, it certainly fails for asking a question.
What about making excessive fields optional instead of removing them? This is where reasonable people disagree. The strict reading of GDPR Article 5(1)(c) holds that “limited to what is necessary” applies to what appears on the form, not merely what is mandatory. If you do not need the data, why is the field there at all? The pragmatic reading — accepted by some DPAs — holds that clearly labelled optional fields with disclosed purposes respect user autonomy. But the conversion research settles it from the business side: the Imagescape study found that total field count, not required-field count, drove form abandonment. Visitors were intimidated by the number of visible fields regardless of which ones had asterisks. Remove the field. Your compliance improves, your conversion rate improves, and you have one fewer data point to store, secure, disclose, and delete.
The data you did not know you were collecting
This is where it gets uncomfortable. Open phpMyAdmin or WP-CLI and run this query against your WordPress database:
SELECT 'WPForms' AS plugin, COUNT(*) AS entries_with_ip
FROM wp_wpforms_entries WHERE ip_address != ''
UNION ALL
SELECT 'Gravity Forms', COUNT(*) FROM wp_gf_entry WHERE ip != ''
UNION ALL
SELECT 'Formidable', COUNT(*) FROM wp_frm_items WHERE ip != ''
UNION ALL
SELECT 'Fluent Forms', COUNT(*) FROM wp_fluentform_submissions WHERE ip != '';
If any of those counts are above zero, your form is collecting IP addresses — personal data under GDPR, confirmed by the CJEU in Breyer v. Germany (C-582/14) — regardless of whether you intended it, configured it, or even knew about it. Every major WordPress form plugin does this by default. Not as an opt-in. As the factory setting.
But IP addresses are just the beginning. Here is what each plugin actually stores behind those three innocent-looking form fields:
WPForms Pro records IP address, user agent string, WordPress user ID for logged-in visitors, and a cookie-based UUID via the wpfuuid cookie — which, incidentally, persists for eleven years. Eleven. That cookie feeds WPForms’ Related Entries, Geolocation, and Form Abandonment features, and it has been tracking returning visitors across your site since the day you activated the plugin.
Gravity Forms stores IP, the full source URL of the page where the form was submitted, user agent, the WordPress user ID of logged-in submitters, and — since version 2.9 — the post/page ID. But it goes further. The wp_gf_form_view table tracks form views, including IP addresses, for visitors who merely see the form without submitting it. Your form is recording data about people who never interacted with it.
Fluent Forms is the most aggressive collector in the WordPress form ecosystem. Beyond IP, browser, device, source URL, and user ID, it stores city and country for every submission — obtained by sending the visitor’s IP address to ipinfo.io, a US-based third-party service, without any disclosure to the visitor. The fluentform_form_analytics table extends this to form views: IP, browser, platform, city, country, and user ID for every visitor who loads a page containing the form, whether they touch it or not. Even incomplete multi-step submissions in fluentform_draft_submissions capture IP, browser, and device data.
Contact Form 7 is the privacy winner by default — it stores nothing in the database, sending submissions only via email. But if you have installed Flamingo for entry storage, it records IP, URL, date, time, and username. And CF7 itself makes IP and user agent available via the [_remote_ip] and [_user_agent] mail tags — if your email template includes these, the data travels through your email infrastructure even without database storage.
The question is not whether your form collects hidden data. It almost certainly does. The question is whether you have ever looked.
The third-party requests your form page fires without telling you
Your plugin’s database is only half the picture. The other half is what happens when the form page loads in a visitor’s browser — before they type a single character.
Google reCAPTCHA v3 is the most significant offender. Unlike the v2 checkbox, v3 activates on page load and runs continuously, monitoring mouse movements, keystroke timing, scroll patterns, and click behaviour. It collects IP addresses, sets multiple cookies, examines existing Google cookies, gathers browser fingerprinting data, and transmits everything to Google’s servers. Your visitor has not submitted your form. They have not even scrolled to it. And their behavioural data is already flowing to Google. CNIL fined Cityscoot €125,000 for exactly this — deploying reCAPTCHA without consent.
Do you know what your form page loads? Open it in an incognito browser window, press F12 to open DevTools, go to the Network tab, and watch. Every request to a domain that is not yours is a data transfer you need to justify. Google Fonts loaded from Google’s CDN? That transmits the visitor’s IP to Google — the Munich Regional Court ruled this a GDPR violation in January 2022, awarding damages and threatening €250,000 per future infringement. Akismet checking submissions for spam? It sends the visitor’s IP, user agent, referrer URL, full message content, and all available server environment variables to Automattic’s US servers.
These are not hypothetical risks. They are observable, testable facts. Ten minutes with browser DevTools will show you exactly what your form page transmits to which third parties. Most site owners have never looked.
Conditional logic: the design pattern that solves minimization
If data minimization sounds like it means stripping your forms down to the bare minimum at the cost of functionality, it does not. The GDPR does not mandate the shortest possible form. It mandates that each field be necessary for the stated purpose. Conditional logic lets you collect purpose-justified data from visitors who need it while not collecting it from visitors who do not.
A phone number field that appears only when someone selects “please call me back” is perfectly compliant. A company name field that shows only when the visitor identifies as a business inquirer is defensible. A file upload that appears only for support requests requiring documentation is appropriate. The data is collected when necessary and not collected when it is not — which is exactly what GDPR Article 25(2) means by “by default, only personal data which are necessary for each specific purpose.”
Every major WordPress form plugin supports this. WPForms, Gravity Forms, Ninja Forms, Formidable Forms, and Fluent Forms all offer conditional logic that shows or hides fields based on user selections. The technical implementation varies — most hide fields via CSS or JavaScript while leaving them in the DOM, though Formidable Forms explicitly clears hidden field values and JetFormBuilder offers a toggle to physically remove hidden elements from the page HTML. Across all tested plugins, conditionally hidden fields do not submit their values, making conditional logic a functionally effective minimization tool.
One caution: multi-step forms with partial entry features — WPForms’ Form Abandonment addon, Fluent Forms’ Partial Entries — save data in real time as visitors progress through steps. A visitor who fills steps one and two of a four-step form but abandons has their data stored without ever clicking submit. That is collection without completion, and it needs its own lawful basis.
How to actually fix this in your plugin
Knowing the problem is useless without the solution. Here is exactly what to change in each major plugin.
WPForms Pro: Navigate to WPForms → Settings → General → GDPR. Enable “GDPR Enhancements,” then toggle on both “Disable User Cookies” and “Disable User Details.” The first kills the eleven-year wpfuuid cookie. The second stops IP and user agent collection. For code-level precision, add this to your theme’s functions.php or a site-specific plugin:
add_filter( 'wpforms_entry_save_args', function( $args, $form_data ) { $args['ip_address'] = ''; $args['user_agent'] = ''; $args['user_id'] = 0; return $args;
}, 10, 2 );
Gravity Forms: Open each form’s Settings → Personal Data tab and check “Prevent IP address from being stored.” That handles IP. But source URL, user agent, and user ID have no UI toggle — you need code:
add_filter( 'gform_ip_address', '__return_empty_string' ); add_filter( 'gform_entry_post_save', function( $entry, $form ) { GFAPI::update_entry_property( $entry['id'], 'source_url', '' ); GFAPI::update_entry_property( $entry['id'], 'user_agent', '' ); GFAPI::update_entry_property( $entry['id'], 'created_by', 0 ); return $entry;
}, 10, 2 );
Note that gform_ip_address filters before the database write, but the post-save approach for other fields means the data briefly exists before being cleared.
Fluent Forms: No admin UI exists for this. Code is the only path:
add_filter( 'fluentform/disable_ip_logging', '__return_true' ); add_filter( 'fluentform/filter_insert_data', function( $data ) { $data['browser'] = ''; $data['device'] = ''; $data['source_url'] = ''; $data['ip'] = ''; $data['city'] = ''; $data['country'] = ''; return $data;
}); add_filter( 'fluentform/ip_provider', '__return_empty_string' );
That last filter kills the ipinfo.io geolocation call.
Formidable Forms: Navigate to Formidable → Global Settings → General → GDPR and check “Disable storing IPs” and “Disable user tracking cookies.” Or use the filter:
add_filter( 'frm_user_ip', '__return_empty_string' );
Contact Form 7: Check your email templates under Contact → [Form Name] → Mail. Remove [_remote_ip] and [_user_agent] if present. If Flamingo is installed, add do_not_store: true in the form’s Additional Settings tab for forms that should not retain submissions.
After making these changes, run the IP audit query again. Existing entries are not retroactively cleaned — you will need to purge old records manually or via SQL.
Fewer fields make more money — the evidence is overwhelming
If the legal argument for data minimization does not move you, the business argument should. The conversion research is not ambiguous. It is overwhelming.
Imagescape reduced their B2B contact form from 11 fields to 4. Conversion rate jumped from 5.4% to 11.9% — a 120% increase — with no decline in lead quality. Formstack analysed 650,000 users across 117,577 forms and found that reducing fields to 4 or fewer increased conversions by 160%. Unbounce’s benchmark report — 41,000 landing pages, 464 million visitors — found that forms with 5 or fewer fields double conversion rates, and phone number fields alone impose a 5% conversion penalty. HubSpot’s analysis of 40,000 landing pages confirmed that age, telephone, and address fields each independently reduce conversion rates.
Does this mean the shortest form always wins? No. Michael Aagaard’s work at Unbounce showed that naively removing engaging fields (event details on a booking form) while keeping friction fields (name, phone) can decrease leads. And HubSpot’s data shows multi-step forms with progressive disclosure convert 86% higher than single-step forms. The principle is not “fewer fields” — it is “only necessary fields.” A 10-field B2B quote form where every field serves the response purpose is compliant and may convert well. A 6-field contact form where three fields serve no purpose is non-compliant and is actively driving visitors away.
The convergence between GDPR and conversion optimisation is not a coincidence. Both frameworks ask the same question: does this field serve the user’s actual need? Every unnecessary field you remove simultaneously reduces compliance risk, lowers abandonment, and shrinks the personal data footprint you must secure, retain, and eventually delete. Data minimization is not a compliance burden. It is a competitive advantage disguised as a legal obligation.
The audit that tells you the truth about your form
You have read the arguments. Now here is how you find out what your form actually does.
First, run the database discovery query to find every form-related table in your installation:
SELECT table_name, table_rows, ROUND(data_length/1024, 2) AS size_kb
FROM information_schema.tables
WHERE table_schema = DATABASE()
AND (table_name LIKE '%wpforms%' OR table_name LIKE '%gf_%' OR table_name LIKE '%fluentform%' OR table_name LIKE '%frm_%' OR table_name LIKE '%nf3%');
Second, run the IP audit query from earlier in this article to check whether IP addresses are being stored.
Third, open your form page in an incognito browser. Open DevTools → Network tab. Filter by third-party domains. Every request you see is a data transfer you need to justify, disclose, and — if it involves cookies or fingerprinting — obtain consent for before it fires.
Fourth, submit a test entry and then query the database for that specific entry. Look at every column. Compare what the visitor typed (name, email, message) against what the database actually stored. The difference between those two lists is your data minimization gap.
That gap — between the three fields a visitor sees and the dozen data points the database records — is where most WordPress contact forms fail GDPR. Closing it is not complicated. It requires knowing what your plugin actually collects, disabling what it does not need to collect, and removing form fields that do not serve the stated purpose. The law requires it. The conversion data supports it. And now you know exactly how to do it.
— Comments 0
No comments yet. Be the first to share your opinion!
LEAVE AN OPINION