Writing a form by hand is not difficult, it is repetitive, and repetitive is where mistakes live: the label whose for does not match an id, the control that lost its name attribute in a copy and paste, the group of radios with no fieldset around it. Generating the markup removes exactly that class of error and nothing else. It is worth being clear about which half of the job that is.
What generated markup gets right by construction
A generator writes the same skeleton every time, which means the parts that are boring to check are simply correct. Every control has a unique id and a label bound to it. Every control that should be submitted has a name. Radio and checkbox groups come wrapped in a fieldset with a legend, so the group has a name a screen reader can announce, which is the single most commonly missing piece of markup in hand-written forms. The input types match the questions, so a phone shows the right keyboard without anybody thinking about it.
What no generator can know
It cannot know your CSS, so the classes it writes are a guess and the focus styles are yours to check. It cannot know your content, so the label text it starts from is a placeholder for the words your visitors will actually understand. Most of all it cannot know where your form should post to, because that depends on how your site is hosted and what you have deployed behind it. Generated markup is a correct skeleton, and the last attribute is always the one you have to fill in yourself.
Read the output before you ship it
The point of generating markup you can see is that you can read it. Take thirty seconds over the output: check the field names are the keys you want on the other end, check the required attributes are on the fields you genuinely will not accept without, and check there is nothing in there you did not ask for. Markup you have read is markup you can maintain, which is the difference between a generator and an embed that drops an opaque widget into your page.
Counting what you are about to write
The size of a form is the thing people misjudge, because a field is not one element. Each control brings its own label, each group of options brings a fieldset and a legend, and a group of several options is several controls sharing one name. The worksheet on the generator page counts all of that from the field list you give it, which is useful before you start rather than after: it is the difference between a short form and one that quietly became a page.
Questions people ask about generate html forms
Is generated markup worse than markup I write myself?
It is the same markup, written more consistently. What it is not is tailored: the class names and the label wording are a starting point, and you should expect to edit both. Nothing about generated output ties you to the tool that wrote it.
Will it write the JavaScript too?
It does not need to. A plain form posts and the browser navigates, with no script involved. If you want submission without leaving the page, that is a small piece of code you add afterwards, and it works better written against markup you already understand.
What still has to be done after generating the form?
Point the action at something that accepts a POST, style it to match your page, and make sure whatever receives the submission validates it again. The first of those is the one that turns a nice-looking form into a working one.