JotForm is one of the most widely used online form builders — with over 20 million users, it’s a popular choice for businesses that want a quick way to build contact forms, surveys, order forms, and more without writing code. If you use JotForm on a WordPress site, this post covers how the integration works, how to capture lead source data from JotForm submissions, and where attribution typically breaks down.
How JotForm Works With WordPress
JotForm is a hosted platform — your forms live on JotForm’s servers, not on WordPress itself. There are two ways to use JotForm on a WordPress site:
Embedded Embed Code
JotForm generates an iFrame or JavaScript embed code for each form. You paste this into a WordPress page using a Custom HTML block or a shortcode. The form loads from JotForm’s servers inside your page. From the visitor’s perspective, the form appears to be part of your site. From a technical perspective, it’s running in a separate domain context.
The iFrame embed is the most common method and the one JotForm recommends. It’s simple, requires no plugin, and forms render consistently. The limitation is that iFrame content is sandboxed — JavaScript running on your WordPress page cannot directly read or write to elements inside the iFrame, and vice versa.
JotForm WordPress Plugin
JotForm offers an official WordPress plugin (available in the WordPress plugin directory) that lets you insert forms using a shortcode or Gutenberg block without manually copying embed code. The plugin authenticates with your JotForm account and pulls your available forms. Under the hood, it still uses the iFrame embed — it just makes the insertion process more convenient.
The Attribution Gap With JotForm
Here’s where JotForm on WordPress creates a common attribution problem: when a visitor submits a JotForm form on your site, where does that submission data go?
It goes to JotForm. JotForm stores it in your JotForm account. If you have JotForm integrated with a CRM (HubSpot, Salesforce, Zoho, etc.) or email tool (Mailchimp, etc.) via JotForm’s built-in integrations, the data flows there too.
What doesn’t automatically travel with the submission: which marketing campaign or channel sent that visitor to your WordPress page in the first place. If the visitor arrived via a Google Ads click with utm_source=google, utm_medium=cpc, utm_campaign=spring_promo — and filled out a JotForm form — that UTM data is not automatically attached to the JotForm submission. It’s sitting in the browser session, and unless something captures it and passes it through, it gets lost at the form submission step.
This means: your CRM has a new lead. You don’t know if they came from Google Ads, organic search, a referral, or a direct visit. Attribution is broken.
How to Pass UTM Data Through JotForm
JotForm supports hidden fields. These are form fields that are not visible to the submitter but are included in the submission data. The standard fix for attribution with JotForm is to add hidden fields for each UTM parameter you want to capture, then populate those fields with the UTM values from the visitor’s URL when the page loads.
The process:
- Add hidden fields to your JotForm form: utm_source, utm_medium, utm_campaign, utm_term, utm_content (and optionally gclid for Google Ads click ID)
- Use JotForm’s “Get the URL parameter” pre-fill option for each hidden field, pointing to the matching parameter name
- When a visitor lands on your WordPress page with UTM parameters in the URL, JotForm reads those values and pre-fills the hidden fields automatically
- When the visitor submits, the UTM data is included in the submission and flows to your CRM or email tool via JotForm’s integrations
JotForm’s URL parameter pre-fill is built in — no JavaScript required. In JotForm’s form builder, under field properties for a hidden field, you’ll find “Get value from URL parameter.” Set this to the UTM parameter name (e.g., utm_source) and JotForm handles the rest.
The Problem With Session-Level UTM Capture
JotForm’s URL parameter pre-fill reads UTMs from the current page URL at the time of form load. This only works when the UTM parameters are present in the URL of the page containing the form.
Consider a common visitor path: a visitor clicks a Google Ad and lands on a landing page with UTMs in the URL. They browse a few pages. Then they navigate to your contact page (a different URL, no UTMs) and fill out your JotForm form. Result: JotForm reads the contact page URL, finds no UTM parameters, and the hidden fields are empty. Attribution is lost even though the lead came from Google Ads.
The JotForm URL parameter approach only reliably captures UTMs when the form is on the landing page the visitor arrived at. Any multi-page path where the visitor moves from a UTM-tagged URL to a non-tagged URL before converting will lose attribution.
For forms on non-landing pages (like a contact page), the more reliable approach is to capture UTM data in a first-party cookie on the initial landing page and read from that cookie when the form loads. This requires JavaScript that writes UTMs to a cookie on page load (or uses sessionStorage/localStorage), and then reads from that store to populate the JotForm hidden fields. JotForm’s built-in URL parameter option cannot read cookies — it only reads the current URL — so this requires custom JavaScript on the WordPress page.
First-Party Attribution Tools for JotForm + WordPress
For businesses that want lead source attribution to work reliably across their entire site — not just on landing pages — a first-party attribution tool handles the complexity automatically.
Tools like Sales Provenance are designed for exactly this use case: they capture the visitor’s original lead source on the first landing page, persist that data across sessions, and provide a way to pull the attribution data into form submissions. Rather than hoping every converting visit carries UTMs in the URL, first-party attribution maintains source data from first touch through conversion regardless of how many pages the visitor browses or how long they take to convert.
The iFrame limitation is worth noting for JotForm specifically: because JotForm forms run inside an iFrame from a different domain, JavaScript on your WordPress page cannot directly write values into JotForm fields. Solutions include JotForm’s URL parameter approach (with a custom script that reads from your attribution cookie and appends UTM values to the iFrame src URL), or using JotForm’s webhook/integration to cross-reference submission data with session attribution data captured elsewhere.
JotForm Integrations and Where Attribution Flows
JotForm has a large native integration library: HubSpot, Salesforce, Zoho CRM, Pipedrive, ActiveCampaign, Mailchimp, Slack, Google Sheets, and many more. When a form submission arrives, JotForm can push the data to one or more of these destinations automatically.
If you’ve added UTM hidden fields to your JotForm form and they’re being captured correctly, those UTM values will flow through JotForm’s integrations as standard form fields. In HubSpot, for example, you’d map the JotForm hidden field “utm_source” to a HubSpot contact property “utm_source” in the integration setup — and from that point, every JotForm submission includes the UTM data in the HubSpot contact record.
The setup requires explicit field mapping in JotForm’s integration configuration. The UTM fields don’t automatically route to the right place in the destination system — you have to tell JotForm what each field maps to. One-time setup, but it’s a step that many businesses skip, which is why UTM data often doesn’t appear in the CRM even when the form technically captures it.
If you want lead source attribution working end-to-end from your WordPress site through JotForm to your CRM, Sales Provenance is built to close this gap.