> Markdown version of [Email Field](https://vaadin.com/docs/next/components/email-field). Section index: [llms.txt](https://vaadin.com/docs/next/components/llms.txt)

# Email Field

Email Field is an extension of Text Field that accepts only email addresses as input. If the given address is invalid, the field is highlighted in red and an error message appears underneath the input.

**Lit** — `email-field-basic.ts`

```html
<vaadin-email-field
  label="Email address"
  name="email"
  value="julia.scheider@email.com"
  error-message="Enter a valid email address"
  clear-button-visible
></vaadin-email-field>

<vaadin-email-field
  label="Email address"
  name="email"
  value="This is not an email"
  error-message="Enter a valid email address"
  clear-button-visible
  invalid
></vaadin-email-field>
```

**Flow** — `EmailFieldBasic.java`

```java
EmailField validEmailField = new EmailField();
validEmailField.setLabel("Email address");
validEmailField.getElement().setAttribute("name", "email");
validEmailField.setValue("julia.scheider@email.com");
validEmailField.setErrorMessage("Enter a valid email address");
validEmailField.setClearButtonVisible(true);

EmailField invalidEmailField = new EmailField();
invalidEmailField.setLabel("Email address");
invalidEmailField.getElement().setAttribute("name", "email");
invalidEmailField.setValue("This is not an email");
invalidEmailField.setErrorMessage("Enter a valid email address");
invalidEmailField.setClearButtonVisible(true);

add(validEmailField, invalidEmailField);
```

**React** — `email-field-basic.tsx`

```tsx
<EmailField
  label="Email address"
  name="email"
  value="julia.scheider@email.com"
  errorMessage="Enter a valid email address"
  clearButtonVisible
/>

<EmailField
  label="Email address"
  name="email"
  value="This is not an email"
  errorMessage="Enter a valid email address"
  clearButtonVisible
  invalid
/>
```

The validity of the email addresses is checked according to the [RFC 5322](https://tools.ietf.org/html/rfc5322#) standard, which includes the format for email addresses.

## <a id="basic-features"></a>Basic Features

The following features, common to most input field components, are supported:

Label

The label is used to identify the input field. It supports plain-text content. In the Lumo theme its length is limited to the width of the field (and truncated with ellipsis), while in the Aura theme labels wrap to multiple lines. [Helpers](#helper) and [Tooltips](#tooltip) can be used to provide additional information that doesn’t fit into the label.

Visible labels are strongly recommended for all input fields. In cases where the built-in label cannot be used, an external element can be associated as the field’s label through the `aria-labelledby` attribute (`setAriaLabelledBy` in Flow). Fields without any visible label should include an invisible label for assistive technologies with the `aria-label` attribute (`setAriaLabel` in Flow).

Helper

Helpers are used to provide additional information that the user may need to enter in the field, such as format requirements or explanations of the field’s purpose below the field.

A [style variant](https://vaadin.com/docs/next/components/email-field/styling.md#style-variants) is available for rendering the helper above the field.

In addition to plain text, helpers can contain components and HTML elements. However, complex and interactive content is likely to have accessibility issues.

Placeholder

The placeholder is text that’s displayed when the field is empty. Its primary purpose is to provide a short input hint (e.g., the expected format) in situations where a [Helper](#helper) cannot be used.

Placeholders should not be used as a replacement for a visible label. They can be mistaken for a manually entered value. See [Label](#label) for alternatives to the built-in field label.

Tooltip

Tooltips are small text pop-ups displayed on hover, and on keyboard-focus. They can be used to provide additional information about a field. This can be useful in situations where an always visible [Helper](#helper) is not appropriate. Helpers are generally recommended in favor of tooltips, though, as they provide much better discoverability and mobile support. See the [Tooltip](https://vaadin.com/docs/next/components/tooltip.md) documentation for more information.

Clear Button

The clear button — which is displayed when the field is not empty — clears the field’s current value. Although the button itself is not keyboard focusable, the clear action can be taken with the `Esc` key, when the field has focus. The clear button can be especially useful in search and filter fields, where users often need to clear the value. They’re less useful, however, in regular forms.

Prefix & Suffix

Prefix and suffix elements — rendered at either end of the field — can be used to display units, icons, and similar visual cues to the field’s purpose or format.

Prefix and suffix elements aren’t automatically announced by screen readers as part of the field. Text content (e.g., in a `Span` or `Div`) that should be announced can be associated with the field (since V25.3) using the `accessible-description-ref` attribute (`setAriaDescribedBy` in Flow). Focusable elements (e.g., buttons) are announced separately when focused.

```html
<vaadin-email-field accessible-description-ref="price-prefix price-suffix">
  <span slot="prefix" id="price-prefix">$</span>
  <span slot="suffix" id="price-suffix">per month</span>
</vaadin-email-field>
```

```java
Span prefix = new Span("$");
prefix.setId("price-prefix");
field.setPrefixComponent(prefix);

Span suffix = new Span("per month");
suffix.setId("price-suffix");
field.setSuffixComponent(suffix);

field.setAriaDescribedBy("price-prefix price-suffix");
```

Associated elements are announced in addition to the field’s helper and error message.

External & Invisible Labels (ARIA)

Visible labels are strongly recommended for all input fields. In situations where the built-in label cannot be used, an external element can be associated as the field’s label through its element `id`. Fields without any visible label should be provided an invisible label for assistive technologies like screen readers.

```html
<!-- Associates external element as label: -->
<label id="external-label">This is the label</label>
<vaadin-email-field accessible-name-ref="external-label">...

<!-- Invisible label for screen readers: -->
<vaadin-email-field accessible-name="This is the label">...
```

```java
// Associates external element as label:
NativeLabel label = new NativeLabel("This is the label");
label.setId("external-label");
field.setAriaLabelledBy("external-label");

// Invisible label for screen readers:
field.setAriaLabel("This is the label");
```

**Lit** — `email-field-basic-features.ts`

```typescript
<vaadin-email-field
  label="Label"
  helper-text="Helper text"
  placeholder="Placeholder"
  clear-button-visible
>
  <vaadin-tooltip slot="tooltip" text="Tooltip text"></vaadin-tooltip>
  <vaadin-icon slot="prefix" icon="vaadin:envelope"></vaadin-icon>
</vaadin-email-field>
```

**Flow** — `EmailFieldBasicFeatures.java`

```java
EmailField field = new EmailField();
field.setLabel("Label");
field.setHelperText("Helper text");
field.setPlaceholder("Placeholder");
field.setTooltipText("Tooltip text");
field.setClearButtonVisible(true);
field.setPrefixComponent(VaadinIcon.ENVELOPE.create());
```

**React** — `email-field-basic-features.tsx`

```tsx
<EmailField label="Label" helperText="Helper text" placeholder="Placeholder" clearButtonVisible>
  <Tooltip slot="tooltip" text="Tooltip text" />
  <Icon slot="prefix" icon="vaadin:envelope" />
</EmailField>
```

## <a id="validation"></a>Validation

Email Field provides a validation mechanism based on constraints. Constraints allow you to define criteria that the value must meet to be considered valid. Validation occurs typically when the user initiates a value change, for example by entering input and pressing `Enter`. If the value is invalid, the field is highlighted in red, and an error message appears underneath the input.

Below is a list of supported constraints with more detailed information:

Required

Required fields are marked with an indicator next to the label, and become invalid if their value is first entered and then cleared.

An instruction text at the top of the form explaining the required indicator is recommended. The indicator itself can be customized with the `--vaadin-input-field-required-indicator` style property.

Pattern

The pattern is a regular expression that specifies an email format. Any value that doesn’t match the email format invalidates the field. By default, the [RFC 5322](https://tools.ietf.org/html/rfc5322#) standard pattern is used. However, you can modify this pattern to add additional restrictions (e.g., to require a specific domain).

The example below uses a modified version of the RFC 5322 pattern and accepts only addresses in the `example.com` domain.

The following example demonstrates how to specify these constraints and provide error messages:

**Lit** — `email-field-validation.ts`

```typescript
<vaadin-email-field
  required
  pattern="^[a-zA-Z0-9_\\-+]+(?:\\.[a-zA-Z0-9_\\-+]+)*@example\\.com$"
  label="Email address"
  helper-text="Only example.com addresses allowed"
  .errorMessage="${this.errorMessage}"
  @validated="${(event: EmailFieldValidatedEvent) => {
    const field = event.target as EmailField;
    const { validity } = field.inputElement as HTMLInputElement;
    if (validity.valueMissing) {
      this.errorMessage = 'Field is required';
    } else if (validity.patternMismatch) {
      this.errorMessage = 'Enter a valid example.com email address';
    } else {
      this.errorMessage = '';
    }
  }}"
></vaadin-email-field>
```

**Flow** — `EmailFieldValidation.java`

```java
EmailField field = new EmailField("Email address");
field.setRequiredIndicatorVisible(true);
field.setPattern(
        "^[a-zA-Z0-9_\\-+]+(?:\\.[a-zA-Z0-9_\\-+]+)*@example\\.com$");

field.setI18n(new EmailFieldI18n()
        .setRequiredErrorMessage("Field is required")
        .setPatternErrorMessage(
                "Enter a valid example.com email address"));
```

**React** — `email-field-validation.tsx`

```tsx
<EmailField
  required
  pattern="^[a-zA-Z0-9_\-+]+(?:\.[a-zA-Z0-9_\-+]+)*@example\.com$"
  label="Email address"
  helperText="Only example.com addresses allowed"
  errorMessage={errorMessage.value}
  onValidated={(event) => {
    const field = event.target as EmailFieldElement;
    const { validity } = field.inputElement as HTMLInputElement;
    if (validity.valueMissing) {
      errorMessage.value = 'Field is required';
    } else if (validity.patternMismatch) {
      errorMessage.value = 'Enter a valid example.com email address';
    } else {
      errorMessage.value = '';
    }
  }}
/>
```

It’s important to ensure an appropriate error message is configured for each constraint violation to provide users with clear feedback.

> **Note: Data Binding & Custom Validation**
>
> Flow and Hilla offer an advanced API called Binder that allows you to bind data and add custom validation rules for multiple fields, creating forms. You can learn more about Binder from the corresponding [Flow](https://vaadin.com/docs/next/flow/binding-data/components-binder-validation.md) and [Hilla](https://vaadin.com/docs/next/hilla/guides/forms/binder-validation.md) articles.

## <a id="read-only-disabled"></a>Read-Only & Disabled

Fields used to display values should be set to `read-only` mode to prevent editing. Read-only fields are focusable and visible to screen readers. They can display tooltips. Their values can be selected and copied.

Fields that are currently unavailable should be `disabled`. The reduced contrast of disabled fields makes them inappropriate for displaying information. They can’t be focused or display tooltips. They’re invisible to screen readers, and their values cannot be selected and copied.

Disabled fields can be useful in situations where they can become enabled based on some user action. Consider hiding fields entirely if there’s nothing the user can do to make them editable.

**Lit** — `email-field-readonly-and-disabled.ts`

```typescript
<vaadin-email-field
  readonly
  label="Read-only"
  value="example@example.com"
></vaadin-email-field>

<vaadin-email-field disabled label="Disabled"></vaadin-email-field>
```

**Flow** — `EmailFieldReadonlyAndDisabled.java`

```java
EmailField readonlyField = new EmailField();
readonlyField.setReadOnly(true);
readonlyField.setLabel("Read-only");
readonlyField.setValue("example@example.com");

EmailField disabledField = new EmailField();
disabledField.setEnabled(false);
disabledField.setLabel("Disabled");
```

**React** — `email-field-readonly-and-disabled.tsx`

```tsx
<EmailField readonly label="Read-only" value="example@example.com" />

<EmailField disabled label="Disabled" />
```

## <a id="value-change-modes-flow"></a>Value Change Modes Flow

With the Flow Java API, you can define when client-side value changes are synchronized to the server. The `ValueChangeMode` enum provides the following modes:

| Mode                  | Synchronization timing                                                                                                                                           | Custom timeout interval |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| `EAGER`               | Synchronizes the value whenever it changes on the client side, for example on each keystroke.                                                                    | No                      |
| `LAZY`                | Synchronizes the value after a defined interval has passed without further changes. If another change occurs before the interval ends, the timeout is restarted. | Yes                     |
| `TIMEOUT`             | Synchronizes the value at defined intervals while the value continues to change.                                                                                 | Yes                     |
| `ON_CHANGE` (default) | Synchronizes the value on the `change` event, when the component value is committed.                                                                             | No                      |

For the modes that support a custom timeout interval, you can change the interval with the `setValueChangeTimeout()` method. The default interval is 400 milliseconds.

**Flow** — `EmailFieldValueChangeMode.java`

```java
var emailField = new EmailField("Email Field");
var modeSelector = new Select<>("Value Change Mode", valueChangeModes);
modeSelector.setValue(emailField.getValueChangeMode());
modeSelector.addValueChangeListener(e -> {
    emailField.clear();
    emailField.setValueChangeMode(e.getValue());
});
var serverSideContent = new Span();
emailField.addValueChangeListener(
        e -> serverSideContent.setText(e.getValue()));
```

`CC0AAD7F-3E1C-4A8E-A331-52F2AEDDD907`