HTML Form Builder

Build HTML forms visually. Add and configure fields, then copy or download the generated HTML.

Form Templates:

Form Fields (5)

Reorder or customize input properties

Field Type

Label Text

Placeholder

Mark as Required field

Field Type

Label Text

Placeholder

Mark as Required field

Field Type

Label Text

Placeholder

Mark as Required field

Field Type

Label Text

Placeholder

Mark as Required field

Field Type

Button Text

Generated HTML

25 lines • 674 B

<form action="" method="post">

  <div>
    <label for="name">Full Name *</label>
    <input type="text" id="name" name="name" placeholder="Jane Doe" required>
  </div>

  <div>
    <label for="email">Email Address *</label>
    <input type="email" id="email" name="email" placeholder="jane@example.com" required>
  </div>

  <div>
    <label for="subject">Subject</label>
    <input type="text" id="subject" name="subject" placeholder="How can we help?">
  </div>

  <div>
    <label for="message">Message *</label>
    <textarea id="message" name="message" required placeholder="Your message..."></textarea>
  </div>

  <button type="submit">Send Message</button>

</form>

Accessible HTML5 markup generated

Total Fields: 5text: 2email: 1textarea: 1submit: 1

HTML Form Builder

Build semantic HTML forms without writing code. Supports all standard input types including text, email, password, number, tel, url, date, file, checkbox, radio buttons, select dropdowns, textareas, and hidden fields. The generated HTML uses proper <label for> associations and includes required attributes for accessibility.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Building a form visually and copying the generated markup.
Getting the input types and attributes right for a field you use rarely.
Producing a starting form you then wire to a handler.
Adding validation attributes without remembering the syntax.
Comparing field types for a particular kind of input.

Frequently Asked Questions

Why does every input need a label?: Because it is what a screen reader announces and what makes the text clickable, which enlarges the touch target. A placeholder is not a label — it disappears on focus, fails contrast requirements, and leaves the field unidentified once typing starts.
Which input type should I use?: The most specific one available. `type="email"`, `tel`, `url`, `number` and `date` bring the right mobile keyboard and free built-in validation. Using `text` for everything is the commonest way a mobile form becomes tedious to complete.
What does autocomplete do?: Tells the browser and password manager what a field is for, using the standard tokens — `given-name`, `email`, `street-address`, `cc-number`. It is a WCAG 1.3.5 requirement, and it is the difference between a form autofilling correctly and not at all.
How should validation errors be announced?: With `aria-invalid` on the field, `aria-describedby` pointing at the message, and the message near the field rather than only in a summary. A red border alone communicates nothing to a screen reader and nothing to a colour-blind user.
Is client-side validation enough?: Never. It is a usability feature and is trivially bypassed — anything the server relies on has to be validated there too. Client validation prevents a wasted round trip; it prevents nothing at all from a determined request.

Common errors and gotchas

Omitting a label associated with each input, which is the single most common form accessibility failure.
Using a placeholder as a label, which disappears the moment someone types.
Relying on client-side validation alone, which any request can bypass.
Omitting `name` attributes, so the fields submit nothing.
Choosing the wrong input type, which loses the mobile keyboard and the built-in validation.