Here is a question that splits the privacy community down the middle: if a contact form field is not necessary for the stated purpose, does GDPR require you to remove it — or is marking it “optional” enough?
You have probably seen both answers stated with equal confidence. The strict camp says the field should not exist. The pragmatic camp says optional fields respect user autonomy. Both cite the same EDPB guidelines. Both claim regulatory support. And until January 2025, neither had a definitive court ruling to settle the argument. Then the CJEU decided Mousse v SNCF Connect, and the ground shifted — not to one side or the other, but to a higher standard that makes the whole debate more urgent for every WordPress site owner running a contact form with a phone number field they added “just in case.”
The two readings of “necessary” and why neither is completely wrong
GDPR Article 5(1)(c) requires personal data to be “adequate, relevant and limited to what is necessary.” The fight is over that last word. Necessary for what? And necessary to whom — the controller or the data subject?
The strict reading says if you do not need the data to fulfil the form’s stated purpose, the field should not be on the form at all. The EDPB supports this at paragraph 49 of Guidelines 4/2019: “the default setting shall not include collection of personal data that is not necessary for the specific processing purpose.” The EDPB Guidelines 3/2022 on dark patterns go further at paragraph 30, instructing controllers not to “ask for additional data such as the phone number, when the data users already provided during the sign-up process are sufficient.” Under this reading, an optional phone number field on an email inquiry form is a violation hiding behind an asterisk convention.
The pragmatic reading says optional fields — empty by default, clearly labelled, voluntarily completed — respect user autonomy. And the EDPB endorses this too. The same Guidelines 4/2019, at paragraph 70, lists “autonomy” as a key design element for the fairness principle, stating data subjects “should be granted the highest degree of autonomy possible to determine the use made of their personal data.” The EDPB’s own bank loan worked example endorses distinguishing between mandatory and optional processing, provided defaults are privacy-protective. The ICO explicitly lists “volunteering optional information for a specific purpose — e.g., filling optional fields in a form” as valid clear affirmative action for consent.
And here is the detail that most commentators miss: GDPR Article 13(2)(e) requires controllers to tell users “whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data.” Why would the regulation require disclosure about whether data provision is obligatory if it never contemplated scenarios where it is not? The legislation itself presupposes that some data collection is optional.
So which reading wins? Neither — completely. The safest ground sits between them: optional fields are permissible where they serve a genuine, documented purpose and are implemented with specific safeguards. But the January 2025 CJEU ruling just raised the bar for what “genuine purpose” means.
The ruling that changed the standard
In Mousse v CNIL and SNCF Connect (CJEU Case C-394/23, 9 January 2025), the French rail operator required customers to select “Monsieur” or “Madame” when buying train tickets online. A single dropdown field. Two options. The CJEU held it violated GDPR Article 5(1)(c), ruling that personalising commercial communication based on presumed gender identity was “not objectively indispensable in order to enable the proper performance of a rail transport contract.”
Read that standard again: objectively indispensable. Not useful. Not conventional. Not helpful for personalisation. Objectively indispensable for the stated purpose. The Court did not ask whether SNCF had a reason for the field. It asked whether the field was indispensable — and found that sending a properly addressed email is not indispensable for selling a train ticket.
Now apply that standard to your WordPress contact form. Your stated purpose is “responding to your enquiry.” Is a phone number field objectively indispensable for responding to an email inquiry? Is a company name field indispensable for answering a question? Is a subject dropdown indispensable when you could simply read the message?
The Mousse ruling concerned a required field, not an optional one. Whether an optional title field would survive the same scrutiny is untested. But the “objectively indispensable” language does not distinguish between required and optional — it constrains what data a controller should even offer to collect. If the data is not objectively indispensable for the purpose, having it on the form at all becomes harder to justify, regardless of whether it carries an asterisk.
When “optional” is actually coercion wearing a label
CNIL fined SAF Logistics €200,000 in September 2023 for a form that collected family members’ identities, employers, marital status, blood type, and political affiliation. The form was voluntary — only employees seeking internal transfers submitted it. SAF Logistics argued that since the form was optional, the data collection was consensual. The CNIL rejected this entirely, finding that employees feared omitting information would disadvantage their candidacy. The consent was not freely given because the power dynamic made “optional” meaningless.
This is not just an employment law problem. It maps directly onto how WordPress contact forms use optional fields. Have you ever seen a form with microcopy next to the phone field saying “helps us serve you better” or “so we can reach you faster”? That is what the EDPB’s Guidelines 3/2022 on dark patterns calls “Emotional Steering” — persuasive language that nudges data disclosure. The EDPB identifies two other patterns equally relevant to optional form fields: “Deceptive Snugness” (placing the optional field between required fields so filling it feels like the natural flow) and “Continuous Prompting” (following up a blank field with a validation-style message like “Are you sure you don’t want to add your phone number?”).
The practical test: would a reasonable user feel they could leave the field blank without consequence, hesitation, or social pressure? If your form’s design, positioning, or microcopy creates even mild doubt, the “(optional)” label is not protecting you. It is decorating a dark pattern.
What your database does with the field you left blank
Here is a technical fact that most WordPress site owners have never considered: when a visitor submits your form and leaves an optional field blank, every major form plugin stores an empty string for that field in the database. Not NULL. Not “field omitted.” An empty string — a record that says “this user’s submission included a phone number field, and the value was nothing.”
WPForms stores it as an empty string in both its JSON blob (wp_wpforms_entries.fields) and its individual field rows (wp_wpforms_entry_fields). Gravity Forms creates a dedicated meta row in wp_gf_entry_meta for every field on the form, including blank optional ones. Formidable Forms does the same in wp_frm_item_metas. Fluent Forms stores empty strings in both fluentform_submissions.response and fluentform_entry_details. Even Contact Form 7, which has no native storage, transmits empty field values through Flamingo into wp_posts as custom post meta.
Why does this matter? Because under a strict reading of GDPR Article 25(2), your system is processing — storing — a data category that was not necessary. When a data subject submits an access request under GDPR Article 15, your export will include records showing “phone number: (empty)” for every submission where the field existed but was not completed. Your automated deletion routines need to account for these empty-string records. And if a DPA audits your database, they will see that your form architecture presupposes the collection of data that you claim is optional.
No major WordPress form plugin offers a built-in setting to omit empty optional fields from storage. If you want to prevent this, you need custom code — hooking into gform_pre_submission for Gravity Forms, wpforms_process_filter for WPForms, fluentform_before_insert_submission for Fluent Forms, or wpcf7_flamingo_inbound_message_parameters for CF7 with Flamingo.
The asterisk problem nobody is solving correctly
Every major WordPress form plugin marks required fields with an asterisk and leaves optional fields unmarked. This is the universal convention, and it is the wrong one — according to the research that actually studied how users interact with it.
Baymard Institute found that when only required fields are marked with asterisks, 32% of users fail to complete required fields because they cannot distinguish which unmarked fields are required and which are optional. The solution — marking required fields with asterisks and optional fields with explicit “(optional)” text — is recommended by both Baymard and Nielsen Norman Group. As of 2021, only 14% of e-commerce sites implement it.
For GDPR compliance, this is not merely a UX consideration. If users cannot tell which fields are required and which are optional, they may fill in optional fields under the mistaken belief that the data is mandatory. Any data collected under that misunderstanding is not freely given — it fails the consent standard that justifies optional field collection in the first place.
WPForms lets you customise the required label via the wpforms_get_field_required_label filter, but adding “(optional)” to non-required fields requires manual label editing. Gravity Forms outputs both a red asterisk and a legend (“* indicates required fields”) with the most robust accessibility implementation — aria-required=”true”, proper fieldset/legend structures, and aria-describedby references. Contact Form 7 distinguishes required from optional purely through tag syntax ([text* field-name] versus [text field-name]) with no visual “(optional)” indicator by default.
If you keep optional fields on your form, at minimum add “(optional)” to their labels. Not doing so creates a form where users cannot determine what is required, which undermines the autonomy argument that justifies having optional fields at all.
Conditional logic makes the whole debate unnecessary
Here is the cleanest solution to the required-versus-optional tension: do not make the field optional. Make it conditional.
A contact form that asks “How would you prefer we respond?” and reveals a phone number field only when the visitor selects “Phone call” satisfies everyone. The strict interpretation is satisfied because the field does not exist by default — GDPR Article 25(2) is met. The pragmatic interpretation is satisfied because the user’s own choice demonstrates the field’s relevance — GDPR Article 5(1)(c) is met. And the user’s affirmative selection constitutes clear consent for that specific purpose — GDPR Article 6(1)(a) is met. Three provisions, one design pattern, zero legal ambiguity.
The implementation quality varies dramatically across WordPress plugins, and this matters for compliance.
Gravity Forms has the strongest implementation. Fields hidden by conditional logic are “completely excluded from the submission. Their values are not saved to the entry and are not available for notifications, calculations, or feed processing.” This is architectural, not cosmetic — the data simply does not exist in the database for hidden fields. This is the gold standard for GDPR-compliant conditional logic.
WPForms (“Smart Logic”) similarly clears values of conditionally hidden fields before submission. Hidden field data is not stored. Available in Pro and above.
Fluent Forms uniquely offers conditional logic in its free version — making it the most accessible option for WordPress site owners who need compliance without a premium plugin budget.
Formidable Forms clears hidden field values but cannot natively toggle a field’s required status based on conditions. Achieving “conditionally required” behaviour — where a phone field is both visible and mandatory only when the user requests a callback — requires custom code via the frm_validate_field_entry hook.
Contact Form 7 has no native conditional logic at all. The third-party “Conditional Fields for Contact Form 7” plugin addresses this, but custom jQuery implementations face a critical problem: hidden fields remain in the DOM and their data will be submitted unless JavaScript explicitly clears the value and removes the required attribute. If you are running CF7 without the conditional fields plugin, you have no compliant way to implement this pattern.
Ninja Forms requires a paid add-on for conditional logic, and historical changelog entries reveal bugs with “required fields that were conditionally hidden” — suggesting the handling has been inconsistent across versions.
One critical distinction to avoid a dangerous mistake: the “Hidden” field type available in Gravity Forms, WPForms, and others is fundamentally different from a conditionally hidden field. Hidden field types always submit and store their values silently — they are used for tracking data like referrer URLs. A Hidden field type containing a user’s IP address is not data-minimisation-by-design. It is invisible data collection. Do not confuse the two.
The conversion data makes this easier than it looks
If the legal complexity feels overwhelming, the business data simplifies the decision dramatically. Optional fields — even when unfilled — cost you submissions.
HubSpot’s analysis of 40,000+ landing pages found each additional field decreases conversions by approximately 4.1%. Expedia removed a single optional “Company Name” field and recovered $12 million in annual revenue — users were entering their bank name, causing payment verification failures. Phone number fields carry the steepest penalty: MarketingSherpa documented a 275% increase in capture rates when phone number moved from required to optional, and the University of Wisconsin-Extension recorded a 52% conversion drop within 24 hours of making phone number mandatory, with 96% statistical confidence.
But does removing fields always help? No. Michael Aagaard’s work showed that cutting a form from 9 to 6 fields decreased leads by 14% — because the removed fields were the engaging, context-relevant ones (event type, performance time) while the retained fields were pure friction (name, email, phone). The lesson is precise: every field must earn its place through either legal necessity or demonstrated user value. Fields that serve neither are dead weight — legally risky and commercially counterproductive.
Multi-step forms offer a path that serves both compliance and conversion. Venture Harbour redesigned a 30-question form into a 4-step process and saw completion rates jump from 10% to 53%. Progressive disclosure lets you collect purpose-justified data at the moment it becomes relevant, which is exactly what conditional logic does at the field level.
Your privacy notice must cover fields nobody fills in
One obligation that WordPress site owners consistently miss: if an optional phone number field exists on your form, your privacy notice must disclose phone number collection — even if 95% of visitors leave it blank. GDPR Article 13(1)(c) requires disclosure of all purposes for which personal data is intended, and this applies to all data the controller may collect, not only data actually collected in a given submission.
GDPR Article 13(2)(e) goes further, requiring you to tell users “whether the data subject is obliged to provide the personal data and of the possible consequences of failure to provide such data.” This means your form needs transparency text — inline, in a tooltip, or in a just-in-time notice — explaining which fields are required, which are optional, why optional data is requested, and what happens if it is not provided.
Every optional field you add to a form is a field you must disclose in your privacy notice, document in your ROPA under GDPR Article 30, assign a legal basis to, secure under GDPR Article 32, include in data subject access responses under GDPR Article 15, and delete on schedule under GDPR Article 5(1)(e). The field may be optional for the visitor. The compliance obligations it creates are not optional for you.
The decision that makes every other decision easier
For every field on your WordPress contact form, run through this sequence. It takes thirty seconds per field, and it resolves the required-versus-optional question definitively for your specific form.
Is the field objectively indispensable for the stated purpose? For a general inquiry form, name and email pass this test. Everything else probably does not.
If not indispensable, does the field serve a genuine secondary purpose with its own legal basis? A phone number serving “providing telephone support when requested” is a distinct purpose requiring its own documentation.
If a genuine secondary purpose exists, can conditional logic eliminate the field for users who do not need it? This is the strongest compliance position and should be the default approach.
If conditional logic is impractical, implement the field as optional with full safeguards — clear “(optional)” labelling, empty by default, no persuasive microcopy, just-in-time transparency, documented legal basis, and privacy notice disclosure.
If none of the above applies, remove the field. It is legally risky, it is commercially counterproductive, and it is creating database records, privacy notice obligations, and DSAR response requirements for data nobody asked for and nobody needs.
The required-versus-optional debate is real, and the legal position is genuinely unsettled. But for most WordPress contact forms, the debate is academic — because most optional fields do not serve a genuine secondary purpose, do not use conditional logic, are not accompanied by proper transparency, and are not even helping conversion rates. They exist because someone added them during setup and nobody questioned whether they should be there. That is not data minimisation by design. That is data accumulation by inertia. And in the year the CJEU told SNCF that a title dropdown fails the “objectively indispensable” test, inertia is not a compliance strategy.
— Comments 0
No comments yet. Be the first to share your opinion!
LEAVE AN OPINION