Salesforce Web-to-Lead: Setup, Best Practices & Limits

Salesforce Web-to-Lead is a native feature that turns a public HTML form into Salesforce Lead records. You generate the form in Setup, paste it on your website, and every submission POSTs to Salesforce's webto.salesforce.com servlet to create a Lead automatically — no API code required.

To make it work you need three things: your Org ID (the hidden oid field), the two always-required fields Last Name and Company, and the form pointed at https://webto.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8. Salesforce processes up to 500 Web-to-Lead requests per org per day by default.

Key takeaways

• Path: Setup → Feature Settings → Marketing → Web-to-Lead → Create Web-to-Lead Form.
• The generated form POSTs to https://webto.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8 and must carry a hidden oid (your Org ID).
• Last Name (last_name) and Company (company) are the only mandatory fields; add retURL, lead_source, and email as needed.
• Turn on reCAPTCHA, assignment rules (with Active Assignment Rule), and auto-response rules before going live.
• The default limit is 500 requests per org per 24 hours; overflow is routed to the default lead owner, who gets a notification email.
• The raw generated markup is unstyled — most teams reskin it or POST the same fields from a custom/server-side form for proper validation.

What is Salesforce Web-to-Lead?

Web-to-Lead is a standard Salesforce feature (available in Group, Professional, Enterprise, Performance, Unlimited, and Developer editions) that captures visitor details from a website form and creates a Lead record in your org. Salesforce generates the HTML, you host it, and inbound submissions flow straight into your pipeline where assignment, auto-response, and solid Salesforce lead management best practices take over.

It is the lead-generation sibling of Web-to-Case, which does the same thing for support Cases.

How do you set up Web-to-Lead in Salesforce?

1. Go to Setup → Feature Settings → Marketing → Web-to-Lead (in older orgs: Setup → Build → Leads → Web-to-Lead).
2. Click Edit, tick Web-to-Lead Enabled, and pick a Default Lead Creator — the user listed as the creator of online leads and the person notified when you exceed the daily limit.
3. Optionally set a Default Response Template for the auto-response, then Save.
4. Click Create Web-to-Lead Form.
5. Move the fields you want into the Selected Fields list (use the add/remove and up/down arrows). Custom fields and a multi-select picklist for product interest are supported.
6. Enter a Return URL (retURL) — the page visitors land on after submitting.
7. Enable reCAPTCHA and paste your reCAPTCHA API key pair to filter spam.
8. Click Generate, then copy the HTML and hand it to your web team.

The generator outputs raw markup like the form below.

<!-- Salesforce Web-to-Lead generated form (reskin before production use) -->
<form action="https://webto.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8" method="POST">

  <!-- Your 15- or 18-character Salesforce Org ID -->
  <input type="hidden" name="oid" value="00Dxx0000001gPz">

  <!-- Where to send the visitor after submit (optional) -->
  <input type="hidden" name="retURL" value="https://www.example.com/thank-you">

  <!-- Tag the acquisition channel (optional) -->
  <input type="hidden" name="lead_source" value="Website">

  <label for="last_name">Last Name</label>
  <input id="last_name" name="last_name" type="text" maxlength="80" required>

  <label for="company">Company</label>
  <input id="company" name="company" type="text" maxlength="40" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" maxlength="80">

  <input type="submit" value="Submit">
</form>

Which Web-to-Lead fields are required vs optional?

Salesforce rejects a submission that is missing a required field or that fails a validation rule — and no Lead is created. At minimum the form must send oid, last_name, and company.

Field	HTML name	Required?	Notes
Org ID	oid	Yes (hidden)	Your 15- or 18-char Salesforce Org ID; identifies the target org
Last Name	last_name	Yes	Lead is not created without it
Company	company	Yes	Core B2B lead field
Email	email	Recommended	Needed for auto-response and duplicate matching
Return URL	retURL	Optional (hidden)	Redirect target after submit
Lead Source	lead_source	Optional (hidden)	Tag the channel, e.g. Website
Any custom field	field API name / ID	Optional	Must match the field's API name or 15-char ID

Note: Salesforce does not support Rich Text Area (RTA) fields on Web-to-Lead forms — any HTML entered is stored as plain text. Date and currency values follow your org's Default Locale and Currency Locale, not the visitor's browser.

Web-to-Lead vs API vs manual entry

Web-to-Lead is the fastest way to capture leads, but it is not the only one. Pick the method that matches your volume and validation needs.

Method	Best for	Validation & spam control	Throughput
Web-to-Lead form	Quick public capture with no backend	Basic — reCAPTCHA + Salesforce validation rules only	500 requests/org/day (default)
REST / Bulk API (or a server-side proxy)	Custom front-ends, marketing sites, high volume	Full — validate, enrich, and de-dupe before insert	Governed by your org's API request limits
Manual / list import	Event lists, low-volume B2B	Human review	One-off Data Import Wizard / Data Loader runs

How do leads get assigned and auto-responded?

Web-to-Lead respects your Lead Assignment Rules, but only when the rule is active and the generated form includes the assignment instruction. While building the form, tick Active Assignment Rule so the assignment hidden input is included; otherwise every online lead falls to the Default Lead Creator/Owner.

Auto-Response Rules send a templated email to the prospect based on lead attributes (for example, region or product interest). Add criteria-based entries plus a catch-all so a lead that matches no rule still receives your default template. For routing and follow-up downstream, pair this with Salesforce escalation rules and broader Salesforce marketing automation.

What are the Web-to-Lead limits?

Limit	Default value	What happens at the cap
Web-to-Lead requests	500 per org per 24 hours	Overflow leads are routed to the Default Lead Creator/Owner, who receives a notification email with the lead details
Field validation	All active validation rules run	If any value is invalid, no Lead is created
Required fields	last_name + company (plus any you mark required)	A missing required value blocks creation
Rich Text Area fields	Not supported	RTA input is converted to plain text

If 500 leads/day is too low, you can ask Salesforce Support to raise the limit.

How do you stop spam and duplicate leads?

Public forms attract bots, so layer your defenses:

• reCAPTCHA — enable it in the Web-to-Lead form generator and supply a reCAPTCHA key pair; this is your only built-in spam control on the raw form.
• Validation rules — required fields, email-format checks, and picklist constraints all run before insert, silently rejecting malformed submissions.
• Duplicate rules + matching rules — configure these on the Lead object so a repeat submission is flagged or blocked instead of creating a duplicate record.
• A server-side proxy — POST the form to your own endpoint first, validate and enrich there, then forward clean data to the Salesforce servlet (or the API). This is the most reliable way to add honeypots, rate limits, and stronger CAPTCHA.

Should you use the raw generated form?

Be honest about what Salesforce hands you: the generated HTML is functional but unstyled, exposes your oid in the page source, and offers minimal validation. In practice, most teams keep the field name attributes Salesforce expects but rebuild the markup to match their site, then either:

• Reskin the raw form and POST directly to the webto.salesforce.com servlet (simplest), or
• POST the same fields from a custom front-end form through a server-side proxy for real validation, honeypots, and analytics, or
• Use Salesforce-native capture — Salesforce Forms, Marketing Cloud Account Engagement (Pardot) forms, or a direct API integration — when you need richer logic, progressive profiling, or higher volume.

If you want this designed, secured, and wired into routing properly, our Salesforce consulting team does exactly this. Need the support-side equivalent? See Web-to-Case and on-demand Email-to-Case.

Frequently Asked Questions

What is Web-to-Lead in Salesforce?

Web-to-Lead is a native Salesforce feature that generates an HTML form which, when submitted on your website, POSTs to Salesforce's webto.salesforce.com servlet and automatically creates a Lead record. It requires no API code — just your Org ID and the required Last Name and Company fields.

How many Web-to-Lead requests does Salesforce allow per day?

By default Salesforce processes up to 500 Web-to-Lead requests per organization per 24 hours. Submissions beyond that cap are routed to the Default Lead Creator/Owner, who receives a notification email containing the lead details. You can ask Salesforce Support to raise the limit.

Which fields are required on a Web-to-Lead form?

Every Web-to-Lead form must send the hidden oid (Org ID) plus last_name (Last Name) and company (Company). Any additional fields you mark as required, or any active validation rule, must also pass — otherwise Salesforce creates no Lead.

How do I assign leads automatically from Web-to-Lead?

Create active Lead Assignment Rules and select "Active Assignment Rule" when generating the form so the assignment input is included. Without an active rule, all web leads are assigned to the Default Lead Creator/Owner set on the Web-to-Lead setup page.

How do I prevent spam from Web-to-Lead forms?

Enable reCAPTCHA in the form generator, rely on validation and duplicate rules on the Lead object, and ideally route submissions through a server-side proxy where you can add honeypots and rate limiting before forwarding clean data to Salesforce.

Is Web-to-Lead the same as Web-to-Case?

No. Web-to-Lead creates Lead records for sales and marketing capture, while Web-to-Case creates Case records for customer support. They share the same servlet-based mechanism and Org ID requirement but target different objects and routing rules.