Hidden fields

Why use hidden fields?

Forms often need context that the respondent can’t (or shouldn’t) provide themselves. Hidden fields solve this by letting you attach metadata to each submission through the URL. This is useful when you already know something about the respondent before they open the form — where they came from, who referred them, or which record they belong to in your system.

• Track traffic sources — know whether a submission came from an email campaign, a social media post, or your website

• Connect to your CRM — pass a contact ID, deal ID, or account ID so the submission links back to the right record

• Personalize follow-ups — capture a name or email you already have, then use it in conditional logic or email notifications

• Multi-form workflows — pass data from one form into the next so respondents don’t repeat themselves

• A/B testing — tag each submission with the variant or experiment the respondent saw

Adding a hidden field

Type / on an empty line and pick Hidden Field from the Layout category. It only works at the top level of the form — not inside a column or a repeating group. Each hidden field has two settings:

• Field type — store a number or text value (text by default)

• Parameter name — the URL parameter that fills this field (e.g. utm_source, contact_id). It is also this field’s key, so it is what a caller sends and what the answer comes back under. See Field keys

URL parameter pre-fill

A parameter name must be URL-safe as written: letters, digits, and - _ . ~ ! * ’ ( ) are safe. Write spaces and other special characters percent-encoded, for example recipient%20name. An empty, invalid, or duplicate parameter name is a publish error — the issue indicator in the toolbar flags it and publishing stops until you fix it.

When a respondent opens your form with a matching parameter in the URL, the hidden field captures that value automatically. For example, if your hidden field’s parameter name is utm_source, the URL below sets the field to newsletter.

https://form.formbase.so/abc123?utm_source=newsletter

You can pass multiple hidden fields at once:

https://form.formbase.so/abc123?utm_source=newsletter&utm_medium=email&contact_id=12345

• Values are read once, when the form opens.

• An empty parameter (?utm_source=) leaves the field empty.

• A number hidden field ignores values that aren’t numbers, so ?score=abc leaves it empty.

• Request links ignore URL parameters. Hidden fields there get their values from the request’s context instead.

On a share link, to show a URL value in a visible field the respondent can edit — say, pre-filling their name — make the hidden field the field’s default value by typing @. See Default values from other fields.

Requests don’t need a hidden field to pre-fill

The hidden-field-plus-@ technique above exists because a share link has only one way in: the URL. Anyone can edit a URL, so a share link can carry a value only through a parameter, and a hidden field is what receives it.

A request has a second, private way in. The caller sets the answers when they create the request, server side, so a request can pre-fill a visible question directly — no hidden field and no @ default involved. The recipient opens the form with the answer already in the box.

• prefill

  — starting answers for visible questions, addressed by field key. The recipient sees them and can change them.

• readonly

  — the subset of those pre-filled keys the recipient may read but not edit.

• context

  — values for hidden fields, which the recipient never sees.

The split is enforced. Sending a visible question’s key in context is rejected, with an error telling you to send it in prefill instead, and the reverse is rejected too. So add a hidden field when you want to carry data you don’t want shown, not merely to pre-fill something.

Common setups

• UTM tracking — create hidden fields named utm_source, utm_medium, and utm_campaign. The form catches them from the URL automatically, and each value saves as a submission column. The Analytics Traffic Sources chart reads utm_source and utm_medium from the URL on its own, with or without hidden fields. Set per-link defaults in the Share dialog.

• CRM integration — pass a contact or deal ID from tools like HubSpot, ActiveCampaign, or Mailchimp. When submissions land in your integrations, the ID ties everything together.

• Referral attribution — each partner gets a unique link with their code in the URL. You see exactly who drove each submission.

• Pre-filled context — pass a customer name or plan tier into a support form. Use it in conditional logic to show different questions, or pipe it into the thank-you page.

• Pre-filled answers — send ?email=jane@example.com from your email tool and make that hidden field the default of the form’s Email question. The respondent sees their address already filled in and only fixes it if it’s wrong.

Viewing hidden field data

In the Submissions table, hidden fields show as their own columns — formbase marks them with an eye-slash icon so you can tell them apart from visible questions. They also appear in exports, integrations (Google Sheets, webhooks, etc.), and the submission detail panel.

Using hidden fields with logic

Hidden fields work as condition sources in conditional logic. A logic rule can read a hidden field’s value and branch — showing different questions, jumping to a page, or updating a calculated field.

For example: pass ?plan=enterprise via the URL. A logic rule checks if the hidden “plan” field equals “enterprise” and jumps to a dedicated page with enterprise-specific questions.

Next steps