HTML id vs name Attributes: Differences in Forms

By the end of this page, you will understand that id identifies an element within the document, while name identifies form data during submission. You will know when to use each attribute, why form controls often need both, and how labels and radio buttons depend on them.

The id and name attributes identify different things for different purposes.

• id identifies one specific HTML element in the current document. Its value must be unique.
• name gives a form control the key under which its value is submitted. Several elements may share a name when that represents one logical field, such as a radio-button group.

Consider this form control:

<input id="email" name="emailAddress" type="email">

Here:

• id="email" lets CSS, JavaScript, URL fragments, and <label> elements target this exact input.
• name="emailAddress" determines the submitted field name. If the user enters ada@example.com, the form data contains emailAddress=ada%40example.com.

A browser generally submits a control only when it has a name. An id alone does not cause a form value to be included in the submitted data.

Using both is common because a control frequently needs both jobs: a unique DOM identity and a submission key. Their values may match for convenience, but they do not have to match.

Think of a form control as a package being prepared for delivery.

• The id is the package's unique tracking label inside your building. It helps a label, stylesheet, or JavaScript code find that exact package.
• The name is the field printed on the delivery form. It tells the recipient what the package contains.

A single input may need both labels. But they answer different questions:

• id: “Which exact element is this?”
• name: “What should this submitted value be called?”

Use id for a unique document identifier and name for submitted form data.

<form action="/signup" method="post">
  <label for="user-email">Email address</label>
  <input
    id="user-email"
    name="email"
    type="email"
    required
  >

  <button type="submit">Sign up</button>
</form>

The for="user-email" attribute on the label matches the input's id. Clicking the label focuses the input.

When the form is submitted, the server receives data equivalent to:

email=the-value-the-user-entered

id without name

<input id="user-email" type="email">

This input can still be labelled and selected with JavaScript, but its value is not included in normal form submission because it has no name.

name without id

<input name="email" type="email">

This input is submitted as email=..., but an explicit <label for="..."> cannot point to it. You can instead wrap it in a label:

<label>
  Email address
  <input name="email" type="email">
</label>

Radio buttons share a name

<fieldset>
  <legend>Contact preference</legend>

  <input id="contact-email" name="contactPreference" type="radio" value="email">
  <label for="contact-email">Email</label>

  <input id="contact-phone" name="contactPreference" type="radio" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Each radio button has a unique id, but both share the same name. The shared name makes them one group, so the user can select only one option. The selected button submits either contactPreference=email or contactPreference=phone.

Trace this form submission:

<form action="/search" method="get">
  <label for="site-search">Search</label>
  <input id="site-search" name="q" value="html forms">
  <button type="submit">Search</button>
</form>

1. The browser reads id="site-search".
2. The label's for="site-search" matches that ID, so clicking Search focuses the input.
3. The input starts with the value html forms.
4. The user submits the form.
5. The browser looks for successful form controls. This input is enabled and has name="q", so it is included.
6. Because the method is get, the browser creates a URL like:

/search?q=html%20forms

1. The id does not appear in the submitted URL. The name, q, becomes the parameter key.

If the input had no name, the browser would submit /search without the q parameter.

• Login forms: name="username" and name="password" provide keys the server uses to read credentials. Unique IDs connect visible labels to the correct controls.
• Search pages: a search input might use name="q", producing URLs such as /search?q=keyboard.
• Filters: multiple checkboxes can use the same name, such as name="category", to submit several selected categories.
• Radio-button choices: radio buttons use one shared name to form a mutually exclusive group, while each option needs its own id for its label.
• JavaScript behavior: scripts can select a specific element with document.getElementById("user-email").
• CSS styling: an ID selector such as #checkout-form can target one particular element, although classes are usually better for reusable styling.
• Page links: a URL fragment such as /help#billing scrolls to the element with id="billing".

In production forms, developers usually give user-editable controls a meaningful name because backend frameworks, FormData, and standard browser submission use it.

<input id="profile-display-name" name="displayName" type="text">

The id is often descriptive of the page and field, which helps avoid duplicates when a page has several components. The name often matches the API or server-side data field, such as displayName.

Reading values with FormData

const form = document.querySelector("#profile-form");
const data = new FormData(form);

console.log(data.get("displayName"));

FormData reads the control by its name, not its ID.

Validation and error messages

A common accessible pattern uses an ID to connect descriptive text to a control:

<label for="password">Password</label>
<input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-help"
>
<p id="password-help">Use at least 12 characters.</p>

The aria-describedby value refers to an element ID. Meanwhile, name="password" is used for the submitted field.

Server-side field names

Some backends support nested names such as:

<input name="address[postalCode]" type="text">

The exact parsing behavior depends on the server framework, but the important point remains: the submitted key comes from name, not id.

Expecting id to submit a form value

This control is not submitted under normal HTML form submission:

<input id="email" type="email">

Add a name:

<input id="email" name="email" type="email">

Reusing an id

Duplicate IDs are invalid and make labels, CSS, and JavaScript ambiguous.

<!-- Incorrect: both elements use the same ID -->
<input id="email" name="primaryEmail">
<input id="email" name="backupEmail">

Use unique IDs:

<input id="primary-email" name="primaryEmail">
<input id="backup-email" name="backupEmail">

Giving radio buttons different names

Different names make radio buttons independent, allowing more than one selection.

<!-- Incorrect for a single-choice group -->
<input type="radio" name="email" value="email">
<input type="radio" name="phone" value="phone">

Use one shared name and distinct IDs:

<input id="contact-email" type="radio" name="contact" value="email">
<input id="contact-phone" type="radio" name="contact" value="phone">

Using the same name unintentionally

Unlike IDs, names are allowed to repeat. However, repeating a name changes the submitted data shape. For example, multiple checked checkboxes named feature may submit multiple feature values. Use this deliberately.

Confusing name with the visible label

name is usually a machine-readable field key. The user-facing description should come from a <label>, not from a cryptic name such as usr_eml.

Styling everything with IDs

An ID selector works, but an ID can be used only once per document and has high CSS specificity. Prefer classes for reusable styles:

<input class="form-control" id="billing-email" name="billingEmail" type="email">

id versus class

• Use id when one element needs a unique identifier, especially for labels and accessibility relationships.
• Use class for reusable styling or behavior shared by many elements.

name versus value

For a form control:

<input name="plan" value="pro" type="radio">

• name="plan" is the submitted key.
• value="pro" is the submitted value when that control is successful.

The resulting form data is plan=pro.

• id identifies one unique element in a document.

• name identifies a submitted form field.

• A form control usually needs name to be included in normal form submission.

• Use label[for] with a control's id:

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

• IDs must not be duplicated.

• Names may repeat.

• Radio buttons in one choice group need the same name and different IDs.

• Checkbox groups can intentionally share a name to submit multiple selected values.

• id can be used by CSS, JavaScript, and URL fragments.

• name is read by form submission and FormData.

• id and name may be identical, but they serve different purposes.

• Disabled controls are not submitted, even if they have a name.

• Unchecked checkboxes and unselected radio buttons are not submitted.

Does every HTML input need both id and name?

No. Use name when the value must be submitted as part of a standard form. Use id when the control needs an explicit label connection, unique JavaScript/CSS targeting, or another ID-based relationship. Many real form fields use both.

Can id and name have the same value?

Yes. This is common for simple forms:

<input id="email" name="email" type="email">

They still have different roles.

Why are HTML radio buttons given the same name?

Matching name values tell the browser that radio buttons are one group. Only one radio button in that group can be selected at a time.

Can multiple elements have the same name in HTML?

Yes. This is valid and useful for radio groups, checkbox groups, and repeated input data. The submitted data may then contain multiple values for the same key.

Can multiple elements have the same ID?

No. An id must be unique within the document. Duplicate IDs can break label associations and make DOM selection unreliable.

Does a label use the input's name or ID?

An explicit label uses the input's id through its for attribute:

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

Is an input without a name submitted?

No. Under normal browser form submission, a control without a name does not contribute a key-value pair.

Does the ID appear in submitted form data?

No. The browser uses name as the submitted field key. The ID is not included merely because it exists.

• HTML forms — Forms define controls, submission methods, and destinations for user-entered data.
• <label> element — Labels use for and id to provide an accessible, clickable description for a control.
• FormData API — JavaScript's FormData reads submitted-style values using control names.
• Input value attribute — name supplies the submitted key, while value supplies the submitted value.
• Radio buttons and checkboxes — Their submission behavior and grouping rules depend heavily on name.
• CSS selectors — ID selectors target unique elements; attribute selectors can target elements by name.
• DOM selection — JavaScript can find a unique element with document.getElementById().
• Web accessibility — IDs connect labels, help text, error messages, and controls through accessible relationships.