← All articles
HTMLForm FieldsValidation

HTML input fields: types, validation, and backend-ready examples

FormsFort Team · · Updated August 10, 2026

Short answer: choose an input type that matches the data, connect it to a visible <label>, give it a meaningful name, and validate the received value on the backend. This is a copyable, backend-ready starting point:

<form action="https://api.formsfort.com/submit" method="POST">
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
<label for="name">Full name</label>
<input type="text" id="name" name="name" autocomplete="name" required />
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email" required />
<button type="submit">Send</button>
</form>

The browser posts name=value pairs to the form action. An input without name is not included. Replace YOUR_ACCESS_KEY with your public FormsFort form key, or generate a complete snippet with the HTML form template generator. The HTML form elements reference helps choose the right control for longer text, choices, and uploads.

Common HTML input types

Use semantic types instead of type="text" everywhere. They influence browser validation, autofill, mobile keyboards, and the meaning available to assistive technology.

TypeUse it forExample name
textNames and short textname
emailEmail addressesemail
telPhone numbersphone
urlWebsite linkswebsite
numberQuantities and measurable numbersquantity
dateCalendar datesstart_date
fileAttachmentsresume
hiddenPublic routing metadatasubject
checkboxIndependent yes/no or multi-selectinterest
radioExactly one choice in a groupplan

Use the HTML input type generator when you know the field but want a ready-to-paste label, attributes, and name.

Labels, IDs, and names are different jobs

id connects a control to its label and must be unique on the page. name is the backend field key and should remain stable for notifications, webhook mappings, and exports. The label text is what visitors see; it can change without changing your data contract.

<label for="company">Company</label>
<input
type="text"
id="company"
name="company"
autocomplete="organization"
maxlength="120"
/>

Do not use a placeholder as the only label. If helper text is needed, connect it with aria-describedby:

<label for="website">Website</label>
<p id="website-hint">Include https:// so we can open the link.</p>
<input type="url" id="website" name="website" aria-describedby="website-hint" placeholder="https://example.com" />

Autocomplete and mobile-friendly choices

Autocomplete tokens such as name, email, tel, and organization let browsers fill information the visitor has already supplied. Use the correct token and do not disable autofill without a real reason. type="tel" is usually better than number for phone numbers because phone values can contain +, spaces, extensions, or leading zeroes.

<label for="phone">Phone</label>
<input type="tel" id="phone" name="phone" autocomplete="tel" inputmode="tel" />
<label for="quantity">Quantity</label>
<input type="number" id="quantity" name="quantity" min="1" max="100" step="1" inputmode="numeric" required />

inputmode suggests a keyboard; it does not replace type validation. Do not use number for ZIP codes, account IDs, or other identifiers where formatting and leading zeroes matter.

Browser validation that helps rather than surprises

Use native constraints for fast feedback, then repeat the rules on the backend:

<label for="work-email">Work email</label>
<input type="email" id="work-email" name="work_email" autocomplete="email" required />
<label for="company-size">Company size</label>
<input type="number" id="company-size" name="company_size" min="1" max="100000" step="1" />
<label for="website-url">Website</label>
<input type="url" id="website-url" name="website" placeholder="https://example.com" />

A required field containing only spaces can pass a naïve server check, so trim values before applying business rules. pattern uses the browser’s regular-expression behavior and may reject a value users consider valid; provide a concrete hint when you use one. min and max constrain numbers and dates but do not protect the backend from a crafted request. Test these boundaries with the HTML form validation tester.

Do not add novalidate just to hide an inconvenient browser message. If custom validation is necessary, preserve keyboard focus, an error summary, and an association between each error and its control.

Hidden fields are context, not secrets

Hidden controls submit like other successful controls, but visitors can inspect them in developer tools. Use them for public context such as a subject, campaign source, or redirect path:

<input type="hidden" name="subject" value="New demo request" />
<input type="hidden" name="source" value="pricing-page" />

Never put API secrets, authorization decisions, or trusted prices in hidden inputs. Treat every field as untrusted input on receipt.

Checkboxes, radios, and files

A checked checkbox contributes its value; an unchecked checkbox contributes nothing. Give repeated checkboxes the same name when your backend supports a list, or use a deliberate naming convention. Radio inputs need a shared name and distinct values; see the HTML radio button guide for grouping and keyboard details.

For uploads, use enctype="multipart/form-data" and a file input with a narrow accept hint. accept filters the file picker but is not a security check; validate size and type after upload.

<form action="https://api.formsfort.com/submit" method="POST" enctype="multipart/form-data">
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
<label for="resume">Resume (PDF or DOCX)</label>
<input type="file" id="resume" name="resume" accept=".pdf,.docx" />
<button type="submit">Apply</button>
</form>

Complete lead-capture form

These fields produce recognizable names for notification messages and follow-up workflows:

<form action="https://api.formsfort.com/submit" method="POST">
<input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
<input type="hidden" name="subject" value="New website lead" />
<label for="lead-name">Name</label>
<input type="text" id="lead-name" name="name" autocomplete="name" required />
<label for="lead-email">Work email</label>
<input type="email" id="lead-email" name="email" autocomplete="email" required />
<label for="lead-company">Company</label>
<input type="text" id="lead-company" name="company" autocomplete="organization" />
<label for="lead-website">Website</label>
<input type="url" id="lead-website" name="website" placeholder="https://example.com" />
<label for="lead-message">What are you planning?</label>
<textarea id="lead-message" name="message" rows="5" maxlength="2000"></textarea>
<input type="checkbox" name="botcheck" style="display:none" tabindex="-1" autocomplete="off" />
<button type="submit">Request a conversation</button>
</form>

For a complete workflow, compare this with the lead capture form guide and form notifications. The HTML contact library templates provide an alternate starting point, while HTML form examples keeps sample intent in one canonical hub.

Input field checklist

  • Every user-facing input has a visible, associated label.
  • Every submitted control has a meaningful name and explicit value where needed.
  • id values are unique and do not double as unstable backend field names.
  • Semantic types and autocomplete tokens match the data.
  • Browser constraints improve feedback, but backend validation remains authoritative.
  • Hidden values and accept hints are treated as editable hints, never secrets.

Frequently asked questions

What does the name attribute do on an input?

The name attribute is the submitted field key. A successful control contributes a name=value pair to a normal form submission.

Which input type should I use for email?

Use input type='email'. It provides browser email checks and a useful email keyboard on mobile devices.

Do hidden inputs get submitted?

Yes, when they have a name and are inside the submitted form. They are useful for public metadata, but visitors can inspect and change them.

Should validation happen only in HTML?

No. HTML validation improves the first interaction; backend validation is required because a client can bypass or modify every browser constraint.

Get started free

Ready to add forms to your static site?

No backend required. Point your HTML form at FormsFort and start receiving submissions in minutes.