<input type="hidden"> - HTML: HyperText Markup Language

<input type="hidden">
=====================

`<input>` elements of type **`hidden`** let web developers include data that cannot be seen or modified by users when a form is submitted. For example, the ID of the content that is currently being ordered or edited, or a unique security token. Hidden inputs are completely invisible in the rendered page, and there is no way to make it visible in the page's content.

**Note:** The `input` and `change` events do not apply to this input type. Hidden inputs cannot be focused even using JavaScript (e.g. `hiddenInput.focus()`).

Value
-----

The `<input>` element's `value` attribute holds a string that contains the hidden data you want to include when the form is submitted to the server. This specifically can't be edited or seen by the user via the user interface, although you could edit the value via browser developer tools.

**Warning:** While the value isn't displayed to the user in the page's content, it is visible—and can be edited—using any browser's developer tools or "View Source" functionality. Do not rely on `hidden` inputs as a form of security.

Additional attributes
---------------------

In addition to the attributes common to all `<input>` elements, `hidden` inputs offer the following attributes.

### name

This is actually one of the common attributes, but it has a special meaning available for hidden inputs. Normally, the `name` attribute functions on hidden inputs just like on any other input. However, when the form is submitted, a hidden input whose `name` is set to `_charset_` will automatically be reported with the value set to the character encoding used to submit the form.

Using hidden inputs
-------------------

As mentioned above, hidden inputs can be used anywhere that you want to include data the user can't see or edit along with the form when it's submitted to the server. Let's look at some examples that illustrate its use.

### Tracking edited content

One of the most common uses for hidden inputs is to keep track of what database record needs to be updated when an edit form is submitted. A typical workflow looks like this:

1. User decides to edit some content they have control over, such as a blog post, or a product entry. They get started by pressing the edit button.
2. The content to be edited is taken from the database and loaded into an HTML form to allow the user to make changes.
3. After editing, the user submits the form, and the updated data is sent back to the server to be updated in the database.

The idea here is that during step 2, the ID of the record being updated is kept in a hidden input. When the form is submitted in step 3, the ID is automatically sent back to the server with the record content. The ID lets the site's server-side component know exactly which record needs to be updated with the submitted data.

You can see a full example of what this might look like in the Examples section below.

### Improving website security

Hidden inputs are also used to store and submit security tokens or *secrets*, for the purposes of improving website security. The basic idea is that if a user is filling in a sensitive form, such as a form on their banking website to transfer some money to another account, the secret they would be provided with would prove that they are who they say they are, and that they are using the correct form to submit the transfer request.

This would stop a malicious user from creating a fake form, pretending to be a bank, and emailing the form to unsuspecting users to trick them into transferring money to the wrong place. This kind of attack is called a Cross Site Request Forgery (CSRF); pretty much any reputable server-side framework uses hidden secrets to prevent such attacks.

**Note:** Placing the secret in a hidden input doesn't inherently make it secure. The key's composition and encoding would do that. The value of the hidden input is that it keeps the secret associated with the data and automatically includes it when the form is sent to the server. You need to use well-designed secrets to actually secure your website.

Validation
----------

Hidden inputs don't participate in constraint validation; they have no real value to be constrained.

Examples
--------

Let's look at how we might implement a simple version of the edit form we described earlier (see Tracking edited content), using a hidden input to remember the ID of the record being edited.

The edit form's HTML might look a bit like this:

```html
<form>
  <div>
    <label for="title">Post title:</label>
    <input type="text" id="title" name="title" value="My excellent blog post" />
  </div>
  <div>
    <label for="content">Post content:</label>
    <textarea id="content" name="content" cols="60" rows="5">
This is the content of my excellent blog post. I hope you enjoy it!
    </textarea>
  </div>
  <div>
    <button type="submit">Update post</button>
  </div>
  <input type="hidden" id="postId" name="postId" value="34657" />
</form>
```

Let's also add some simple CSS:

```css
html {
  font-family: sans-serif;
}

form {
  width: 500px;
}

div {
  display: flex;
  margin-bottom: 10px;
}

label {
  flex: 2;
  line-height: 2;
  text-align: right;
  padding-right: 20px;
}

input,
textarea {
  flex: 7;
  font-family: sans-serif;
  font-size: 1.1rem;
  padding: 5px;
}

textarea {
  height: 60px;
}
```

The server would set the value of the hidden input with the ID "`postID`" to the ID of the post in its database before sending the form to the user's browser and would use that information when the form is returned to know which database record to update with modified information. No scripting is needed in the content to handle this.

The output looks like this:

**Note:** You can also find the example on GitHub (see the source code, and also see it running live).

When submitted, the form data sent to the server will look something like this:

`title=My+excellent+blog+post&content=This+is+the+content+of+my+excellent+blog+post.+I+hope+you+enjoy+it!&postId=34657`

Even though the hidden input cannot be seen at all, its data is still submitted.

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** |
 A string representing the value of the hidden
 data you want to pass back to the server.
  |
| **Events** | None. |
| **Supported Common Attributes** | `autocomplete` |
| **IDL attributes** | `value` |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | None. |
| **Implicit ARIA Role** | `no corresponding role` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # hidden-state-(type=hidden) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTML forms guide
* `<input>` and the `HTMLInputElement` interface it's based upon


<input type="image"> - HTML: HyperText Markup Language

<input type="image">
====================

`<input>` elements of type **`image`** are used to create graphical submit buttons, i.e. submit buttons that take the form of an image rather than text.

Try it
------

Value
-----

`<input type="image">` elements do not accept `value` attributes. The path to the image to be displayed is specified in the `src` attribute.

Additional attributes
---------------------

In addition to the attributes shared by all `<input>` elements, `image` button inputs support the following attributes.

### alt

The `alt` attribute provides an alternate string to use as the button's label if the image cannot be shown (due to error, a user agent that cannot or is configured not to show images, or if the user is using a screen reading device). If provided, it must be a non-empty string appropriate as a label for the button.

For example, if you have a graphical button that shows an image with an icon and/or image text "Login Now", you should also set the `alt` attribute to something like `Login Now`.

**Note:** While the `alt` attribute is technically optional, you should always include one to maximize the usability of your content.

Functionally, the `alt` attribute of the `<input type="image">` element works just like the `alt` attribute on `<img>` elements.

### formaction

A string indicating the URL to which to submit the data. This takes precedence over the `action` attribute on the `<form>` element that owns the `<input>`.

This attribute is also available on `<input type="submit">` and `<button>` elements.

### formenctype

A string that identifies the encoding method to use when submitting the form data to the server. There are three permitted values:

`application/x-www-form-urlencoded`

This, the default value, sends the form data as a string after URL encoding the text using an algorithm such as `encodeURI()`.

`multipart/form-data`

Uses the `FormData` API to manage the data, allowing for files to be submitted to the server. You *must* use this encoding type if your form includes any `<input>` elements of `type` `file` (`<input type="file">`).

`text/plain`

Plain text; mostly useful only for debugging, so you can easily see the data that's to be submitted.

If specified, the value of the `formenctype` attribute overrides the owning form's `action` attribute.

This attribute is also available on `<input type="submit">` and `<button>` elements.

### formmethod

A string indicating the HTTP method to use when submitting the form's data; this value overrides any `method` attribute given on the owning form. Permitted values are:

`get`

A URL is constructed by starting with the URL given by the `formaction` or `action` attribute, appending a question mark ("?") character, then appending the form's data, encoded as described by `formenctype` or the form's `enctype` attribute. This URL is then sent to the server using an HTTP `get` request. This method works well for simple forms that contain only ASCII characters and have no side effects. This is the default value.

`post`

The form's data is included in the body of the request that is sent to the URL given by the `formaction` or `action` attribute using an HTTP `post` request. This method supports complex data and file attachments.

`dialog`

This method is used to indicate that the button closes the dialog with which the input is associated, and does not transmit the form data at all.

This attribute is also available on `<input type="submit">` and `<button>` elements.

### formnovalidate

A Boolean attribute which, if present, specifies that the form should not be validated before submission to the server. This overrides the value of the `novalidate` attribute on the element's owning form.

This attribute is also available on `<input type="submit">` and `<button>` elements.

### formtarget

A string which specifies a name or keyword that indicates where to display the response received after submitting the form. The string must be the name of a **browsing context** (that is, a tab, window, or `<iframe>`. A value specified here overrides any target given by the `target` attribute on the `<form>` that owns this input.

In addition to the actual names of tabs, windows, or inline frames, there are a few special keywords that can be used:

`_self`

Loads the response into the same browsing context as the one that contains the form. This will replace the current document with the received data. This is the default value used if none is specified.

`_blank`

Loads the response into a new, unnamed, browsing context. This is typically a new tab in the same window as the current document, but may differ depending on the configuration of the user agent.

`_parent`

Loads the response into the parent browsing context of the current one. If there is no parent context, this behaves the same as `_self`.

`_top`

Loads the response into the top-level browsing context; this is the browsing context that is the topmost ancestor of the current context. If the current context is the topmost context, this behaves the same as `_self`.

This attribute is also available on `<input type="submit">` and `<button>` elements.

### height

A number specifying the height, in CSS pixels, at which to draw the image specified by the `src` attribute.

### src

A string specifying the URL of the image file to display to represent the graphical submit button. When the user interacts with the image, the input is handled like any other button input.

### width

A number indicating the width at which to draw the image, in CSS pixels.

Obsolete attributes
-------------------

The following attribute was defined by HTML 4 for `image` inputs, but was not implemented by all browsers and has since been deprecated.

### usemap

If `usemap` is specified, it must be the name of an image map element, `<map>`, that defines an image map to use with the image. This usage is obsolete; you should switch to using the `<img>` element when you want to use image maps.

Using image inputs
------------------

The `<input type="image">` element is a replaced element (an element whose content isn't generated or directly managed by the CSS layer), behaving in much the same way as a regular `<img>` element, but with the capabilities of a submit button.

### Essential image input features

Let's look at a basic example that includes all the essential features you'd need to use (These work exactly the same as they do on the `<img>` element.):

```html
<input
 id="image"
 type="image"
 width="100"
 height="30"
 alt="Login"
 src="https://raw.githubusercontent.com/mdn/learning-area/master/html/forms/image-type-example/login.png" />
```

* The `src` attribute is used to specify the path to the image you want to display in the button.
* The `alt` attribute provides alt text for the image, so screen reader users can get a better idea of what the button is used for. It will also display if the image can't be shown for any reason (for example if the path is misspelled). If possible, use text which matches the label you'd use if you were using a standard submit button.
* The `width` and `height` attributes are used to specify the width and height the image should be shown at, in pixels. The button is the same size as the image; if you need the button's hit area to be bigger than the image, you will need to use CSS (e.g. `padding`). Also, if you specify only one dimension, the other is automatically adjusted so that the image maintains its original aspect ratio.
### Overriding default form behaviors

`<input type="image">` elements — like regular submit buttons — can accept a number of attributes that override the default form behavior:

`formaction`

The URI of a program that processes the information submitted by the input element; overrides the `action` attribute of the element's form owner.

`formenctype`

Specifies the type of content that is used to submit the form to the server. Possible values are:

* `application/x-www-form-urlencoded`: The default value if the attribute is not specified.
* `text/plain`.

If this attribute is specified, it overrides the `enctype` attribute of the element's form owner.

`formmethod`

Specifies the HTTP method that the browser uses to submit the form. Possible values are:

* `post`: The data from the form is included in the body of the form and is sent to the server.
* `get`: The data from the form is appended to the **`form`** attribute URI, with a '?' as a separator, and the resulting URI is sent to the server. Use this method when the form has no side effects and contains only ASCII characters.

If specified, this attribute overrides the `method` attribute of the element's form owner.

`formnovalidate`

A Boolean attribute specifying that the form is not to be validated when it is submitted. If this attribute is specified, it overrides the `novalidate` attribute of the element's form owner.

`formtarget`

A name or keyword indicating where to display the response that is received after submitting the form. This is a name of, or keyword for, a *browsing context* (for example, tab, window, or inline frame). If this attribute is specified, it overrides the `target` attribute of the element's form owner. The following keywords have special meanings:

* \_`self`: Load the response into the same browsing context as the current one. This value is the default if the attribute is not specified.
* `_blank`: Load the response into a new unnamed browsing context.
* `_parent`: Load the response into the parent browsing context of the current one. If there is no parent, this option behaves the same way as `_self`.
* `_top`: Load the response into the top-level browsing context (that is, the browsing context that is an ancestor of the current one, and has no parent). If there is no parent, this option behaves the same as `_self`.

### Using the x and y data points

When you submit a form using a button created with `<input type="image">`, two extra data points are submitted to the server automatically by the browser — `x` and `y`. You can see this in action in our X Y coordinates example.

When you click on the image to submit the form, you'll see the data appended to the URL as parameters, for example `?x=52&y=55`. If the image input has a `name` attribute, then keep in mind that the specified name is prefixed on every attribute, so if the `name` is `position`, then the returned coordinates would be formatted in the URL as `?position.x=52&position.y=55`. This, of course, applies to all other attributes as well.

These are the X and Y coordinates of the image that the mouse clicked on to submit the form, where (0,0) is the top-left of the image and the default in case submission happens without a click on the image. These can be used when the position the image was clicked on is significant, for example you might have a map that when clicked, sends the coordinates that were clicked to the server. The server-side code then works out what location was clicked on, and returns information about places nearby.

In our above example, we could write server-side code that works out what color was clicked on by the coordinates submitted, and keeps a tally of the favorite colors people voted for.

### Adjusting the image's position and scaling algorithm

You can use the `object-position` property to adjust the positioning of the image within the `<input>` element's frame, and the `object-fit` property to control how the image's size is adjusted to fit within the frame. This allows you to specify a frame for the image using the `width` and `height` attributes to set aside space in the layout, then adjust where within that space the image is located and how (or if) it is scaled to occupy that space.

Examples
--------

### A login form

The following example shows the same button as before, but included in the context of a typical login form.

#### HTML

```html
<form>
  <p>Login to your account</p>
  <div>
    <label for="userId">User ID</label>
    <input type="text" id="userId" name="userId" />
  </div>
  <div>
    <label for="pwd">Password</label>
    <input type="password" id="pwd" name="pwd" />
  </div>
  <div>
    <input
 id="image"
 type="image"
 src="https://raw.githubusercontent.com/mdn/learning-area/master/html/forms/image-type-example/login.png"
 alt="Login"
 width="100" />
  </div>
</form>
```

#### CSS

And now some simple CSS to make the basic elements sit more neatly:

```css
div {
  margin-bottom: 10px;
}

label {
  display: inline-block;
  width: 70px;
  text-align: right;
  padding-right: 10px;
}
```

### Adjusting the image position and scaling

In this example, we adapt the previous example to set aside more space for the image and then adjust the actual image's size and positioning using `object-fit` and `object-position`.

#### HTML

```html
<form>
  <p>Login to your account</p>
  <div>
    <label for="userId">User ID</label>
    <input type="text" id="userId" name="userId" />
  </div>
  <div>
    <label for="pwd">Password</label>
    <input type="password" id="pwd" name="pwd" />
  </div>
  <div>
    <input
 id="image"
 type="image"
 src="https://raw.githubusercontent.com/mdn/learning-area/master/html/forms/image-type-example/login.png"
 alt="Login"
 width="200"
 height="100" />
  </div>
</form>
```

#### CSS

```css
div {
  margin-bottom: 10px;
}

label {
  display: inline-block;
  width: 70px;
  text-align: right;
  padding-right: 10px;
}

#image {
  object-position: right top;
  object-fit: contain;
  background-color: #ddd;
}
```

Here, `object-position` is configured to draw the image in the top-right corner of the element, while `object-fit` is set to `contain`, which indicates that the image should be drawn at the largest size that will fit within the element's box without altering its aspect ratio. Note the visible grey background of the element still visible in the area not covered by the image.

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** | None — the `value` attribute should not be specified. |
| **Events** | None. |
| **Supported common attributes** | `alt`,
 `src`,
 `width`,
 `height`,
 `formaction`,
 `formenctype`,
 `formmethod`,
 `formnovalidate`,
 `formtarget` |
| **IDL attributes** | None. |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | None. |
| **Implicit ARIA Role** | `button` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # image-button-state-(type=image) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `<input>` and the `HTMLInputElement` interface which implements it.
* The HTML `<img>` element
* Positioning and sizing the image within the `<input>` element's frame: `object-position` and `object-fit`
* Compatibility of CSS properties


<input type="color"> - HTML: HyperText Markup Language

<input type="color">
====================

`<input>` elements of type **`color`** provide a user interface element that lets a user specify a color, either by using a visual color picker interface or by entering the color into a text field in `#rrggbb` hexadecimal format.

Only simple colors (without alpha channel) are allowed though CSS colors has more formats, e.g. color names, functional notations and a hexadecimal format with an alpha channel.

The element's presentation may vary substantially from one browser and/or platform to another—it might be a simple textual input that automatically validates to ensure that the color information is entered in the proper format, or a platform-standard color picker, or some kind of custom color picker window.

Try it
------

Value
-----

The `value` of an `<input>` element of type `color` is always a string which contains a 7-character string specifying an RGB color in hexadecimal format. While you can input the color in either upper- or lower-case, it will be stored in lower-case form. The value is never in any other form, and is never empty.

**Note:** Setting the value to anything that isn't a valid, fully-opaque, RGB color *in hexadecimal notation* will result in the value being set to `#000000`. In particular, you can't use CSS's standardized color names, or any CSS function syntax, to set the value. This makes sense when you keep in mind that HTML and CSS are separate languages and specifications. In addition, colors with an alpha channel are not supported; specifying a color in 9-character hexadecimal notation (e.g. `#009900aa`) will also result in the color being set to `#000000`.

Using color inputs
------------------

Inputs of type `color` are simple, due to the limited number of attributes they support.

### Providing a default color

You can update the simple example above to set a default value, so that the color picker is pre-filled with the default color and the color picker (if any) will also default to that color:

```html
<input type="color" value="#ff0000" />
```

If you don't specify a value, the default is `#000000`, which is black. The value must be in seven-character hexadecimal notation, meaning the "#" character followed by two digits each representing red, green, and blue, like this: `#rrggbb`. If you have colors that are in any other format (such as CSS color names or CSS color functions such as `rgb()` or `hsl()` ), you'll have to convert them to hexadecimal before setting the `value`.

### Tracking color changes

As is the case with other `<input>` types, there are two events that can be used to detect changes to the color value: `input` and `change`. `input` is fired on the `<input>` element every time the color changes. The `change` event is fired when the user dismisses the color picker. In both cases, you can determine the new value of the element by looking at its `value`.

Here's an example that watches changes over time to the color value:

```js
colorPicker.addEventListener("input", updateFirst, false);
colorPicker.addEventListener("change", watchColorPicker, false);

function watchColorPicker(event) {
  document.querySelectorAll("p").forEach((p) => {
    p.style.color = event.target.value;
  });
}
```

### Selecting the value

When a browser doesn't support a color picker interface, its implementation of color inputs will be a text box that validates the contents automatically to ensure that the value is in the correct format. In this case you can use the `select()` method to select the text currently in the edit field.

If the browser instead uses a color picker, `select()` does nothing. You should be aware of this behavior so your code can respond appropriately in either case.

```js
colorPicker.select();
```

Validation
----------

A color input's value is considered to be invalid if the user agent is unable to convert the user's input into seven-character lower-case hexadecimal notation. If and when this is the case, the `:invalid` pseudo-class is applied to the element.

Example
-------

Let's create an example which does a little more with the color input by tracking the `change` and `input` events to take the new color and apply it to every `<p>` element in the document.

### HTML

The HTML is fairly straightforward — a couple of paragraphs of descriptive material with an `<input>` of type `color` with the ID `color-picker`, which we'll use to change the color of the paragraphs' text.

```html
<p>
  An example demonstrating the use of the
  <code><input type="color"></code> control.
</p>

<label for="color-picker">Color:</label>
<input type="color" value="#ff0000" id="color-picker" />

<p>
  Watch the paragraph colors change when you adjust the color picker. As you
  make changes in the color picker, the first paragraph's color changes, as a
  preview (this uses the <code>input</code> event). When you close the color
  picker, the <code>change</code> event fires, and we detect that to change
  every paragraph to the selected color.
</p>
```

### JavaScript

First, there's some setup. Here we establish some variables, setting up a variable that contains the color we'll set the color picker to when we first load up, and then setting up a `load` handler to do the main startup work once the page is fully loaded.

```js
let colorPicker;
const defaultColor = "#0000ff";

window.addEventListener("load", startup, false);
```

#### Initialization

Once the page is loaded, our `load` event handler, `startup()`, is called:

```js
function startup() {
  colorPicker = document.querySelector("#color-picker");
  colorPicker.value = defaultColor;
  colorPicker.addEventListener("input", updateFirst, false);
  colorPicker.addEventListener("change", updateAll, false);
  colorPicker.select();
}
```

This gets a reference to the color `<input>` element in a variable called `colorPicker`, then sets the color input's value to the value in `defaultColor`. Then the color input's `input` event is set up to call our `updateFirst()` function, and the `change` event is set to call `updateAll()`. These are both seen below.

Finally, we call `select()` to select the text content of the color input if the control is implemented as a text field (this has no effect if a color picker interface is provided instead).

#### Reacting to color changes

We provide two functions that deal with color changes. The `updateFirst()` function is called in response to the `input` event. It changes the color of the first paragraph element in the document to match the new value of the color input. Since `input` events are fired every time an adjustment is made to the value (for example, if the brightness of the color is increased), these will happen repeatedly as the color picker is used.

```js
function updateFirst(event) {
  const p = document.querySelector("p");
  if (p) {
    p.style.color = event.target.value;
  }
}
```

When the color picker is dismissed, indicating that the value will not change again (unless the user re-opens the color picker), a `change` event is sent to the element. We handle that event using the `updateAll()` function, using `Event.target.value` to obtain the final selected color:

```js
function updateAll(event) {
  document.querySelectorAll("p").forEach((p) => {
    p.style.color = event.target.value;
  });
}
```

This sets the color of every `<p>` block so that its `color` attribute matches the current value of the color input, which is referred to using `event.target`.

### Result

The final result looks like this:

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** |
 A 7-character string specifying a
 `<color>` in lower-case hexadecimal notation
  |
| **Events** | `change` and
 `input` |
| **Supported common attributes** | `autocomplete` and
 `list` |
| **IDL attributes** | `list` and `value` |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | `select()` |
| **Implicit ARIA Role** | `no corresponding role` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # color-state-(type=color) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Compatibility of CSS properties


<input type="datetime-local"> - HTML: HyperText Markup Language

<input type="datetime-local">
=============================

`<input>` elements of type **`datetime-local`** create input controls that let the user easily enter both a date and a time, including the year, month, and day as well as the time in hours and minutes.

Try it
------

The control's UI varies in general from browser to browser. In browsers with no support, these degrade gracefully to simple `<input type="text">` controls.

The control is intended to represent *a local date and time*, not necessarily *the user's local date and time*. In other words, the input allows any valid combination of year, month, day, hour, and minute—even if such a combination is invalid in the user's local time zone (such as the one hour within a daylight saving time spring-forward transition gap).

Value
-----

A string representing the value of the date entered into the input. The format of the date and time value used by this input type is described in Local date and time strings.

You can set a default value for the input by including a date and time inside the `value` attribute, like so:

```html
<label for="party">Enter a date and time for your party booking:</label>
<input
 id="party"
 type="datetime-local"
 name="partydate"
 value="2017-06-01T08:30" />
```

One thing to note is that the displayed date and time formats differ from the actual `value`; the displayed date and time are formatted according to the user's locale as reported by their operating system, whereas the date/time `value` is always formatted `YYYY-MM-DDThh:mm`. When the above value is submitted to the server, for example, it will look like `partydate=2024-06-01T08:30`.

**Note:** Also bear in mind that if such data is submitted via HTTP `GET`, the colon character will need to be escaped for inclusion in the URL parameters, e.g. `partydate=2024-06-01T08%3A30`. See `encodeURI()` for one way to do this.

You can also get and set the date value in JavaScript using the `HTMLInputElement` `value` property, for example:

```js
const dateControl = document.querySelector('input[type="datetime-local"]');
dateControl.value = "2017-06-01T08:30";
```

Additional attributes
---------------------

In addition to the attributes common to all `<input>` elements, `datetime-local` inputs offer the following attributes.

### max

The latest date and time to accept. If the `value` entered into the element is later than this timestamp, the element fails constraint validation. If the value of the `max` attribute isn't a valid string that follows the format `YYYY-MM-DDThh:mm`, then the element has no maximum value.

This value must specify a date string later than or equal to the one specified by the `min` attribute.

### min

The earliest date and time to accept; timestamps earlier than this will cause the element to fail constraint validation. If the value of the `min` attribute isn't a valid string that follows the format `YYYY-MM-DDThh:mm`, then the element has no minimum value.

This value must specify a date string earlier than or equal to the one specified by the `max` attribute.

### step

The `step` attribute is a number that specifies the granularity that the value must adhere to, or the special value `any`, which is described below. Only values which are equal to the basis for stepping (`min` if specified, `value` otherwise, and an appropriate default value if neither of those is provided) are valid.

A string value of `any` means that no stepping is implied, and any value is allowed (barring other constraints, such as `min` and `max`).

**Note:** When the data entered by the user doesn't adhere to the stepping configuration, the user agent may round to the nearest valid value, preferring numbers in the positive direction when there are two equally close options.

For `datetime-local` inputs, the value of `step` is given in seconds, with a scaling factor of 1000 (since the underlying numeric value is in milliseconds). The default value of `step` is 60, indicating 60 seconds (or 1 minute, or 60,000 milliseconds).

*At this time, it's unclear what a value of `any` means for `step` when used with `datetime-local` inputs. This will be updated as soon as that information is determined.*

Using datetime-local inputs
---------------------------

Date/time inputs are convenient for the developer; they provide an easy UI for choosing dates and times, and they normalize the data format sent to the server, regardless of the user's locale. However, it is important to consider your users. Don't require your users to enter data that is not needed for your app to function.

### Controlling input size

`<input type="datetime-local">` doesn't support form control sizing attributes such as `size`. You'll have to resort to CSS for customizing the sizes of these elements.

### Setting timezones

One thing the `datetime-local` input type doesn't provide is a way to set the time zone and/or locale of the date/time control. This was available in the `datetime` input type, but this type is now obsolete, having been removed from the spec. The main reasons why this was removed are a lack of implementation in browsers and concerns over the user interface/experience. It is easier to just have a control (or controls) for setting the date/time and then deal with the locale in a separate control.

For example, if you are creating a system where the user is likely to already be logged in, with their locale already set, you could provide the timezone in a `hidden` input type. For example:

```html
<input type="hidden" id="timezone" name="timezone" value="-08:00" />
```

On the other hand, if you were required to allow the user to enter a time zone along with a date/time input, you could have a `<select>` element to enable the user to set the right time zone by choosing a particular location from among a set of locations:

```html
<select name="timezone" id="timezone">
  <option value="Pacific/Kwajalein">Eniwetok, Kwajalein</option>
  <option value="Pacific/Midway">Midway Island, Samoa</option>
  <option value="Pacific/Honolulu">Hawaii</option>
  <option value="Pacific/Marquesas">Taiohae</option>
  <!-- and so on -->
</select>
```

In either case, the date/time and time zone values would be submitted to the server as separate data points, and then you'd need to store them appropriately in the database on the server-side.

Validation
----------

By default, `<input type="datetime-local">` does not apply any validation to entered values. The UI implementations generally don't let you enter anything that isn't a date/time — which is helpful — but a user might still fill in no value and submit, or enter an invalid date and/or time (e.g. the 32nd of April).

You can use `min` and `max` to restrict the available dates (see Setting maximum and minimum dates), and you can use the `required` attribute to make filling in the date/time mandatory. As a result, supporting browsers will display an error if you try to submit a date that is outside the set bounds or an empty date field.

Let's look at an example; here we've set minimum and maximum date/time values, and also made the field required:

```html
<form>
  <div>
    <label for="party">
      Choose your preferred party date and time (required, June 1st 8.30am to
      June 30th 4.30pm):
    </label>
    <input
 id="party"
 type="datetime-local"
 name="partydate"
 min="2017-06-01T08:30"
 max="2017-06-30T16:30"
 required />
    <span class="validity"></span>
  </div>
  <div>
    <input type="submit" value="Book party!" />
  </div>
</form>
```

If you try to submit the form with an incomplete date (or with a date outside the set bounds), the browser displays an error. Try playing with the example now:

Here's the CSS used in the above example. Here we make use of the `:valid` and `:invalid` CSS properties to style the input based on whether the current value is valid. We put the icons on a `<span>` next to the input.

```css
div {
  margin-bottom: 10px;
  display: flex;
  align-items: center;
}

label {
  display: inline-block;
  width: 300px;
}

input:invalid + span::after {
  content: "✖";
  padding-left: 5px;
}

input:valid + span::after {
  content: "✓";
  padding-left: 5px;
}
```

**Warning:** HTML form validation is *not* a substitute for scripts that ensure that the entered data is in the proper format. It's far too easy for someone to make adjustments to the HTML that allow them to bypass the validation, or to remove it entirely. It's also possible for someone to bypass your HTML entirely and submit the data directly to your server. If your server-side code fails to validate the data it receives, problems can arise when improperly-formatted data is submitted (or data that is too large, is of the wrong type, and so forth).

**Note:** With a `datetime-local` input, the date value is always normalized to the format `YYYY-MM-DDThh:mm`.

Examples
--------

### Basic uses of datetime-local

The simplest use of `<input type="datetime-local">` involves a basic `<input>` and `<label>` element combination, as seen below:

```html
<form>
  <label for="party">Enter a date and time for your party booking:</label>
  <input id="party" type="datetime-local" name="partydate" />
</form>
```

### Setting maximum and minimum dates and times

You can use the `min` and `max` attributes to restrict the dates/times that can be chosen by the user. In the following example, we are setting a minimum datetime of `2024-06-01T08:30` and a maximum datetime of `2024-06-30T16:30`:

```html
<form>
  <label for="party">Enter a date and time for your party booking:</label>
  <input
 id="party"
 type="datetime-local"
 name="partydate"
 min="2024-06-01T08:30"
 max="2024-06-30T16:30" />
</form>
```

Only days in June 2024 can be selected. Depending on what browser you are using, times outside the specified values might not be selectable. In other browsers, invalid dates and times are selectable but will match `:invalid` and `:out-of-range` and will fail validation.

In some browsers (Chrome and Edge), only the "days" part of the date value will be editable, and dates outside June can't be scrolled. In others (Safari), the date picker will appear to allow any date, but the value will be clamped to the valid range when a date is selected.

The valid range included all times between the `min` and `max` values; the time of day is only constrained on the first and last dates in the range.

**Note:** You should be able to use the `step` attribute to vary the number of days jumped each time the date is incremented (e.g. maybe you only want to make Saturdays selectable). However, this does not seem to work effectively in any implementation at the time of writing.

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** |
 A string representing a date and time (in the
 local time zone), or empty.
  |
| **Events** | `change` and
 `input` |
| **Supported common attributes** | `autocomplete`,
 `list`,
 `readonly`, and
 `step` |
| **IDL attributes** | `list`, `value`, `valueAsNumber`. |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | `select()`,
 `stepDown()`,
 `stepUp()` |
| **Implicit ARIA Role** | `no corresponding role` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # local-date-and-time-state-(type=datetime-local) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The generic `<input>` element and the interface used to manipulate it, `HTMLInputElement`
* `<input type="date">` and `<input type="time">`
* Date and time formats used in HTML
* Date and Time picker tutorial
* Compatibility of CSS properties


<input type="password"> - HTML: HyperText Markup Language

<input type="password">
=======================

`<input>` elements of type **`password`** provide a way for the user to securely enter a password.

 The element is presented as a one-line plain text editor control in which the text is obscured so that it cannot be read, usually by replacing each character with a symbol such as the asterisk ("\*") or a dot ("•").
 This character will vary depending on the user agent and operating system.

Try it
------

 The precise behavior of the entry process may vary from browser to browser.
 Some browsers display the typed character for a moment before obscuring it, while others allow the user to toggle the display of plain-text on and off.
 Both approaches help a user check that they entered the intended password, which can be particularly difficult on mobile devices.

**Note:** Any forms involving sensitive information like passwords (such as login forms) should be served over HTTPS.
 Many browsers now implement mechanisms to warn against insecure login forms; see Insecure passwords.

Value
-----

The `value` attribute contains a string whose value is the current contents of the text editing control being used to enter the password. If the user hasn't entered anything yet, this value is an empty string (`""`). If the `required` property is specified, then the password edit box must contain a value other than an empty string to be valid.

If the `pattern` attribute is specified, the content of a `password` control is only considered valid if the value passes validation; see Validation for more information.

**Note:** The line feed (U+000A) and carriage return (U+000D) characters are not permitted in a `password` value. When setting the value of a password control, line feed and carriage return characters are stripped out of the value.

Additional attributes
---------------------

In addition to the attributes that operate on all `<input>` elements regardless of their type, password field inputs support the following attributes.

### maxlength

The maximum string length (measured in UTF-16 code units) that the user can enter into the password field. This must be an integer value of 0 or higher. If no `maxlength` is specified, or an invalid value is specified, the password field has no maximum length. This value must also be greater than or equal to the value of `minlength`.

The input will fail constraint validation if the length of the text entered into the field is greater than `maxlength` UTF-16 code units long.

### minlength

The minimum string length (measured in UTF-16 code units) that the user can enter into the password entry field. This must be a non-negative integer value smaller than or equal to the value specified by `maxlength`. If no `minlength` is specified, or an invalid value is specified, the password input has no minimum length.

The input will fail constraint validation if the length of the text entered into the field is fewer than `minlength` UTF-16 code units long.

### pattern

The `pattern` attribute, when specified, is a regular expression that the input's `value` must match for the value to pass constraint validation. It must be a valid JavaScript regular expression, as used by the `RegExp` type, and as documented in our guide on regular expressions; the `'u'` flag is specified when compiling the regular expression, so that the pattern is treated as a sequence of Unicode code points, instead of as ASCII. No forward slashes should be specified around the pattern text.

If the specified pattern is not specified or is invalid, no regular expression is applied and this attribute is ignored completely.

**Note:** Use the `title` attribute to specify text that most browsers will display as a tooltip to explain what the requirements are to match the pattern. You should also include other explanatory text nearby.

Use of a pattern is strongly recommended for password inputs, in order to help ensure that valid passwords using a wide assortment of character classes are selected and used by your users. With a pattern, you can mandate case rules, require the use of some number of digits and/or punctuation characters, and so forth. See the section Validation for details and an example.

### placeholder

The `placeholder` attribute is a string that provides a brief hint to the user as to what kind of information is expected in the field. It should be a word or short phrase that demonstrates the expected type of data, rather than an explanatory message. The text *must not* include carriage returns or line feeds.

If the control's content has one directionality (LTR or RTL) but needs to present the placeholder in the opposite directionality, you can use Unicode bidirectional algorithm formatting characters to override directionality within the placeholder; see How to use Unicode controls for bidi text for more information.

**Note:** Avoid using the `placeholder` attribute if you can. It is not as semantically useful as other ways to explain your form, and can cause unexpected technical issues with your content. See `<input>` labels for more information.

### readonly

A Boolean attribute which, if present, means this field cannot be edited by the user. Its `value` can, however, still be changed from JavaScript code that directly sets the value of the `HTMLInputElement.value` property.

**Note:** Because a read-only field cannot have a value, `required` does not have any effect on inputs with the `readonly` attribute also specified.

### size

The `size` attribute is a numeric value indicating how many characters wide the input field should be. The value must be a number greater than zero, and the default value is 20. Since character widths vary, this may or may not be exact and should not be relied upon to be so; the resulting input may be narrower or wider than the specified number of characters, depending on the characters and the font (`font` settings in use).

This does *not* set a limit on how many characters the user can enter into the field. It only specifies approximately how many can be seen at a time. To set an upper limit on the length of the input data, use the `maxlength` attribute.

Using password inputs
---------------------

Password input boxes generally work just like other textual input boxes; the main difference is the obscuring of the content to prevent people near the user from reading the password.

### A simple password input

Here we see the most basic password input, with a label established using the `<label>` element.

```html
<label for="userPassword">Password: </label>
<input id="userPassword" type="password" />
```

### Allowing autocomplete

To allow the user's password manager to automatically enter the password, specify the `autocomplete` attribute. For passwords, this should typically be one of the following:

`on`

Allow the browser or a password manager to automatically fill out the password field. This isn't as informative as using either `current-password` or `new-password`.

`off`

Don't allow the browser or password manager to automatically fill out the password field. Note that some software ignores this value, since it's typically harmful to users' ability to maintain safe password practices.

`current-password`

Allow the browser or password manager to enter the current password for the site. This provides more information than `on` does, since it lets the browser or password manager automatically enter currently-known password for the site in the field, but not to suggest a new one.

`new-password`

Allow the browser or password manager to automatically enter a new password for the site; this is used on "change your password" and "new user" forms, on the field asking the user for a new password. The new password may be generated in a variety of ways, depending on the password manager in use. It may fill in a new suggested password, or it might show the user an interface for creating one.

```html
<label for="userPassword">Password:</label>
<input id="userPassword" type="password" autocomplete="current-password" />
```

### Making the password mandatory

To tell the user's browser that the password field must have a valid value before the form can be submitted, specify the Boolean `required` attribute.

```html
<label for="userPassword">Password: </label>
<input id="userPassword" type="password" required />
<input type="submit" value="Submit" />
```

### Specifying an input mode

If your recommended (or required) password syntax rules would benefit from an alternate text entry interface than the standard keyboard, you can use the `inputmode` attribute to request a specific one. The most obvious use case for this is if the password is required to be numeric (such as a PIN). Mobile devices with virtual keyboards, for example, may opt to switch to a numeric keypad layout instead of a full keyboard, to make entering the password easier. If the PIN is for one-time use, set the `autocomplete` attribute to either `off` or `one-time-code` to suggest that it's not saved.

```html
<label for="pin">PIN: </label>
<input id="pin" type="password" inputmode="numeric" />
```

### Setting length requirements

As usual, you can use the `minlength` and `maxlength` attributes to establish minimum and maximum acceptable lengths for the password. This example expands on the previous one by specifying that the user's PIN must be at least four and no more than eight digits. The `size` attribute is used to ensure that the password entry control is eight characters wide.

```html
<label for="pin">PIN:</label>
<input
 id="pin"
 type="password"
 inputmode="numeric"
 minlength="4"
 maxlength="8"
 size="8" />
```

### Selecting text

As with other textual entry controls, you can use the `select()` method to select all the text in the password field.

#### HTML

```html
<label for="userPassword">Password: </label>
<input id="userPassword" type="password" size="12" />
<button id="selectAll">Select All</button>
```

#### JavaScript

```js
document.getElementById("selectAll").onclick = () => {
  document.getElementById("userPassword").select();
};
```

#### Result

You can also use `selectionStart` and `selectionEnd` to get (or set) what range of characters in the control are currently selected, and `selectionDirection` to know which direction selection occurred in (or will be extended in, depending on your platform; see its documentation for an explanation). However, given that the text is obscured, the usefulness of these is somewhat limited.

Validation
----------

If your application has character set restrictions or any other requirement for the actual content of the entered password, you can use the `pattern` attribute to establish a regular expression to be used to automatically ensure that your passwords meet those requirements.

In this example, only values consisting of at least four and no more than eight hexadecimal digits are valid.

```html
<label for="hexId">Hex ID: </label>
<input
 id="hexId"
 type="password"
 pattern="[0-9a-fA-F]{4,8}"
 title="Enter an ID consisting of 4-8 hexadecimal digits"
 autocomplete="new-password" />
```

Examples
--------

### Requesting a Social Security number

This example only accepts input which matches the format for a valid United States Social Security Number. These numbers, used for tax and identification purposes in the US, are in the form "123-45-6789". Assorted rules for what values are permitted in each group exist as well.

#### HTML

```html
<label for="ssn">SSN:</label>
<input
 type="password"
 id="ssn"
 inputmode="numeric"
 minlength="9"
 maxlength="12"
 pattern="(?!000)([0-6]\d{2}|7([0-6]\d|7[012]))([ -])?(?!00)\d\d\3(?!0000)\d{4}"
 required
 autocomplete="off" />
<br />
<label for="ssn">Value:</label>
<span id="current"></span>
```

This uses a `pattern` which limits the entered value to strings representing legal Social Security numbers. Obviously, this regexp doesn't guarantee a valid SSN (since we don't have access to the Social Security Administration's database), but it does ensure the number could be one; it generally avoids values that cannot be valid. In addition, it allows the three groups of digits to be separated by a space, a dash ("-"), or nothing.

The `inputmode` is set to `numeric` to encourage devices with virtual keyboards to switch to a numeric keypad layout for easier entry. The `minlength` and `maxlength` attributes are set to 9 and 12, respectively, to require that the value be at least nine and no more than 12 characters (the former without separating characters between the groups of digits and the latter with them). The `required` attribute is used to indicate that this control must have a value. Finally, `autocomplete` is set to `off` to avoid password managers and session restore features trying to set its value, since this isn't a password at all.

#### JavaScript

This is just some simple code to display the entered SSN onscreen so you can see it. Obviously this defeats the purpose of a password field, but it's helpful for experimenting with the `pattern`.

```js
const ssn = document.getElementById("ssn");
const current = document.getElementById("current");

ssn.oninput = (event) => {
  current.textContent = ssn.value;
};
```

#### Result

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** | A string representing a password, or empty |
| **Events** | `change` and
 `input` |
| **Supported Common Attributes** | `autocomplete`,
 `inputmode`,
 `maxlength`,
 `minlength`,
 `pattern`,
 `placeholder`,
 `readonly`,
 `required`, and
 `size` |
| **IDL attributes** | `selectionStart`, `selectionEnd`,
 `selectionDirection`, and `value` |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | `select()`,
 `setRangeText()`,
 and
 `setSelectionRange()` |
| **Implicit ARIA Role** | `no corresponding role` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # password-state-(type=password) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Compatibility of CSS properties


<input type="tel"> - HTML: HyperText Markup Language

<input type="tel">
==================

`<input>` elements of type **`tel`** are used to let the user enter and edit a telephone number. Unlike `<input type="email">` and `<input type="url">`, the input value is not automatically validated to a particular format before the form can be submitted, because formats for telephone numbers vary so much around the world.

Try it
------

Despite the fact that inputs of type `tel` are functionally identical to standard `text` inputs, they do serve useful purposes; the most quickly apparent of these is that mobile browsers — especially on mobile phones — may opt to present a custom keypad optimized for entering phone numbers. Using a specific input type for telephone numbers also makes adding custom validation and handling of phone numbers more convenient.

**Note:** Browsers that don't support type `tel` fall back to being a standard text input.

Value
-----

The `<input>` element's `value` attribute contains a string that either represents a telephone number or is an empty string (`""`).

Additional attributes
---------------------

In addition to the attributes that operate on all `<input>` elements regardless of their type, telephone number inputs support the following attributes.

### list

The values of the list attribute is the `id` of a `<datalist>` element located in the same document. The `<datalist>` provides a list of predefined values to suggest to the user for this input. Any values in the list that are not compatible with the `type` are not included in the suggested options. The values provided are suggestions, not requirements: users can select from this predefined list or provide a different value.

### maxlength

The maximum string length (measured in UTF-16 code units) that the user can enter into the telephone number field. This must be an integer value of 0 or higher. If no `maxlength` is specified, or an invalid value is specified, the telephone number field has no maximum length. This value must also be greater than or equal to the value of `minlength`.

The input will fail constraint validation if the length of the text entered into the field is greater than `maxlength` UTF-16 code units long.

### minlength

The minimum string length (measured in UTF-16 code units) that the user can enter into the telephone number field. This must be a non-negative integer value smaller than or equal to the value specified by `maxlength`. If no `minlength` is specified, or an invalid value is specified, the telephone number input has no minimum length.

The telephone number field will fail constraint validation if the length of the text entered into the field is fewer than `minlength` UTF-16 code units long.

### pattern

The `pattern` attribute, when specified, is a regular expression that the input's `value` must match for the value to pass constraint validation. It must be a valid JavaScript regular expression, as used by the `RegExp` type, and as documented in our guide on regular expressions; the `'u'` flag is specified when compiling the regular expression so that the pattern is treated as a sequence of Unicode code points, instead of as ASCII. No forward slashes should be specified around the pattern text.

If the specified pattern is not specified or is invalid, no regular expression is applied and this attribute is ignored completely.

**Note:** Use the `title` attribute to specify text that most browsers will display as a tooltip to explain what the requirements are to match the pattern. You should also include other explanatory text nearby.

See Pattern validation below for details and an example.

### placeholder

The `placeholder` attribute is a string that provides a brief hint to the user as to what kind of information is expected in the field. It should be a word or short phrase that demonstrates the expected type of data, rather than an explanatory message. The text *must not* include carriage returns or line feeds.

If the control's content has one directionality (LTR or RTL) but needs to present the placeholder in the opposite directionality, you can use Unicode bidirectional algorithm formatting characters to override directionality within the placeholder; see How to use Unicode controls for bidi text for more information.

**Note:** Avoid using the `placeholder` attribute if you can. It is not as semantically useful as other ways to explain your form, and can cause unexpected technical issues with your content. See `<input>` labels for more information.

### readonly

A Boolean attribute which, if present, means this field cannot be edited by the user. Its `value` can, however, still be changed by JavaScript code directly setting the `HTMLInputElement` `value` property.

**Note:** Because a read-only field cannot have a value, `required` does not have any effect on inputs with the `readonly` attribute also specified.

### size

The `size` attribute is a numeric value indicating how many characters wide the input field should be. The value must be a number greater than zero, and the default value is 20. Since character widths vary, this may or may not be exact and should not be relied upon to be so; the resulting input may be narrower or wider than the specified number of characters, depending on the characters and the font (`font` settings in use).

This does *not* set a limit on how many characters the user can enter into the field. It only specifies approximately how many can be seen at a time. To set an upper limit on the length of the input data, use the `maxlength` attribute.

Non-standard attributes
-----------------------

The following non-standard attributes are available to telephone number input fields. As a general rule, you should avoid using them unless it can't be helped.

### autocorrect

A Safari extension, the `autocorrect` attribute is a string which indicates whether to activate automatic correction while the user is editing this field. Permitted values are:

`on`

Enable automatic correction of typos, as well as processing of text substitutions if any are configured.

`off`

Disable automatic correction and text substitutions.

### mozactionhint
Deprecated

A Mozilla extension, which provides a hint as to what sort of action will be taken if the user presses the `Enter` or `Return` key while editing the field.

**Deprecated: Use `enterkeyhint` instead.**

Using tel inputs
----------------

Telephone numbers are a very commonly collected type of data on the web. When creating any kind of registration or e-commerce site, for example, you will likely need to ask the user for a telephone number, whether for business purposes or for emergency contact purposes. Given how commonly-entered phone numbers are, it's unfortunate that a "one size fits all" solution for validating phone numbers is not practical.

Fortunately, you can consider the requirements of your own site and implement an appropriate level of validation yourself. See Validation, below, for details.

### Custom keyboards

One of the main advantages of `<input type="tel">` is that it causes mobile browsers to display a special keyboard for entering phone numbers. For example, here's what the keypads look like on a couple of devices.

| Firefox for Android | WebKit iOS (Safari/Chrome/Firefox) |
| --- | --- |
| Firefox for Android screen shot | Firefox for iOS screenshot |

### A simple tel input

In its most basic form, a tel input can be implemented like this:

```html
<label for="telNo">Phone number:</label>
<input id="telNo" name="telNo" type="tel" />
```

There is nothing magical going on here. When submitted to the server, the above input's data would be represented as, for example, `telNo=+12125553151`.

### Placeholders

Sometimes it's helpful to offer an in-context hint as to what form the input data should take. This can be especially important if the page design doesn't offer descriptive labels for each `<input>`. This is where **placeholders** come in. A placeholder is a value that demonstrates the form the `value` should take by presenting an example of a valid value, which is displayed inside the edit box when the element's `value` is `""`. Once data is entered into the box, the placeholder disappears; if the box is emptied, the placeholder reappears.

Here, we have an `tel` input with the placeholder `123-4567-8901`. Note how the placeholder disappears and reappears as you manipulate the contents of the edit field.

```html
<input id="telNo" name="telNo" type="tel" placeholder="123-4567-8901" />
```

### Controlling the input size

You can control not only the physical length of the input box, but also the minimum and maximum lengths allowed for the input text itself.

#### Physical input element size

The physical size of the input box can be controlled using the `size` attribute. With it, you can specify the number of characters the input box can display at a time. In this example, for instance, the `tel` edit box is 20 characters wide:

```html
<input id="telNo" name="telNo" type="tel" size="20" />
```

#### Element value length

The `size` is separate from the length limitation on the entered telephone number. You can specify a minimum length, in characters, for the entered telephone number using the `minlength` attribute; similarly, use `maxlength` to set the maximum length of the entered telephone number.

The example below creates a 20-character wide telephone number entry box, requiring that the contents be no shorter than 9 characters and no longer than 14 characters.

```html
<input
 id="telNo"
 name="telNo"
 type="tel"
 size="20"
 minlength="9"
 maxlength="14" />
```

**Note:** The above attributes do affect Validation — the above example's inputs will count as invalid if the length of the value is less than 9 characters, or more than 14. Most browser won't even let you enter a value over the max length.

### Providing default options

#### Providing a single default using the value attribute

As always, you can provide a default value for an `tel` input box by setting its `value` attribute:

```html
<input id="telNo" name="telNo" type="tel" value="333-4444-4444" />
```

#### Offering suggested values

Taking it a step further, you can provide a list of default phone number values from which the user can select. To do this, use the `list` attribute. This doesn't limit the user to those options, but does allow them to select commonly-used telephone numbers more quickly. This also offers hints to `autocomplete`. The `list` attribute specifies the ID of a `<datalist>` element, which in turn contains one `<option>` element per suggested value; each `option`'s `value` is the corresponding suggested value for the telephone number entry box.

```html
<label for="telNo">Phone number: </label>
<input id="telNo" name="telNo" type="tel" list="defaultTels" />

<datalist id="defaultTels">
  <option value="111-1111-1111"></option>
  <option value="122-2222-2222"></option>
  <option value="333-3333-3333"></option>
  <option value="344-4444-4444"></option>
</datalist>
```

With the `<datalist>` element and its `<option>`s in place, the browser will offer the specified values as potential values for the phone number; this is typically presented as a popup or drop-down menu containing the suggestions. While the specific user experience may vary from one browser to another, typically clicking in the edit box presents a drop-down of the suggested phone numbers. Then, as the user types, the list is adjusted to show only filtered matching values. Each typed character narrows down the list until the user makes a selection or types a custom value.

Here's a screenshot of what that might look like:

![An input box has focus with a blue focus ring. The input has a drop-down menu showing four phone numbers the user can select.](/en-US/docs/Web/HTML/Element/input/tel/phone-number-with-options.png)

Validation
----------

As we've touched on before, it's quite difficult to provide a one-size-fits-all client-side validation solution for phone numbers. So what can we do? Let's consider some options.

**Warning:** HTML form validation is *not* a substitute for server-side scripts that ensure the entered data is in the proper format before it is allowed into the database. It's far too easy for someone to make adjustments to the HTML that allow them to bypass the validation, or to remove it entirely. It's also possible for someone to bypass your HTML entirely and submit the data directly to your server. If your server-side code fails to validate the data it receives, disaster could strike when improperly-formatted data (or data which is too large, is of the wrong type, and so forth) is entered into your database.

### Making telephone numbers required

You can make it so that an empty input is invalid and won't be submitted to the server using the `required` attribute. For example, let's use this HTML:

```html
<form>
  <div>
    <label for="telNo">Enter a telephone number (required): </label>
    <input id="telNo" name="telNo" type="tel" required />
    <span class="validity"></span>
  </div>
  <div>
    <button>Submit</button>
  </div>
</form>
```

And let's include the following CSS to highlight valid entries with a checkmark and invalid entries with a cross:

```css
div {
  margin-bottom: 10px;
  position: relative;
}

input[type="number"] {
  width: 100px;
}

input + span {
  padding-right: 30px;
}

input:invalid + span::after {
  position: absolute;
  content: "✖";
  padding-left: 5px;
  color: #8b0000;
}

input:valid + span::after {
  position: absolute;
  content: "✓";
  padding-left: 5px;
  color: #009000;
}
```

The output looks like this:

### Pattern validation

If you want to further restrict entered numbers so they also have to conform to a specific pattern, you can use the `pattern` attribute, which takes as its value a regular expression that entered values have to match.

In this example we'll use the same CSS as before, but our HTML is changed to look like this:

```html
<form>
  <div>
    <label for="telNo">
      Enter a telephone number (in the form xxx-xxx-xxxx):
    </label>
    <input
 id="telNo"
 name="telNo"
 type="tel"
 required
 pattern="[0-9]{3}-[0-9]{3}-[0-9]{4}" />
    <span class="validity"></span>
  </div>
  <div>
    <button>Submit</button>
  </div>
</form>
```

```
div {
  margin-bottom: 10px;
  position: relative;
}

input[type="number"] {
  width: 100px;
}

input + span {
  padding-right: 30px;
}

input:invalid + span::after {
  position: absolute;
  content: "✖";
  padding-left: 5px;
  color: #8b0000;
}

input:valid + span::after {
  position: absolute;
  content: "✓";
  padding-left: 5px;
  color: #009000;
}
```

Notice how the entered value is reported as invalid unless the pattern xxx-xxx-xxxx is matched; for instance, 41-323-421 won't be accepted. Neither will 800-MDN-ROCKS. However, 865-555-6502 will be accepted. This particular pattern is obviously only useful for certain locales — in a real application you'd probably have to vary the pattern used depending on the locale of the user.

Examples
--------

In this example, we present a simple interface with a `<select>` element that lets the user choose which country they're in, and a set of `<input type="tel">` elements to let them enter each part of their phone number; there is no reason why you can't have multiple `tel` inputs.

Each input has a `placeholder` attribute to show a hint to sighted users about what to enter into it, a `pattern` to enforce a specific number of characters for the desired section, and an `aria-label` attribute to contain a hint to be read out to screen reader users about what to enter into it.

```html
<form>
  <div>
    <label for="country">Choose your country:</label>
    <select id="country" name="country">
      <option>UK</option>
      <option selected>US</option>
      <option>Germany</option>
    </select>
  </div>
  <div>
    <p>Enter your telephone number:</p>
    <span class="areaDiv">
      <input
 id="areaNo"
 name="areaNo"
 type="tel"
 required
 placeholder="Area code"
 pattern="[0-9]{3}"
 aria-label="Area code" />
      <span class="validity"></span>
    </span>
    <span class="number1Div">
      <input
 id="number1"
 name="number1"
 type="tel"
 required
 placeholder="First part"
 pattern="[0-9]{3}"
 aria-label="First part of number" />
      <span class="validity"></span>
    </span>
    <span class="number2Div">
      <input
 id="number2"
 name="number2"
 type="tel"
 required
 placeholder="Second part"
 pattern="[0-9]{4}"
 aria-label="Second part of number" />
      <span class="validity"></span>
    </span>
  </div>
  <div>
    <button>Submit</button>
  </div>
</form>
```

The JavaScript is relatively simple — it contains an `onchange` event handler that, when the `<select>` value is changed, updates the `<input>` element's `pattern`, `placeholder`, and `aria-label` to suit the format of telephone numbers in that country/territory.

```js
const selectElem = document.querySelector("select");
const inputElems = document.querySelectorAll("input");

selectElem.onchange = () => {
  for (let i = 0; i < inputElems.length; i++) {
    inputElems[i].value = "";
  }

  if (selectElem.value === "US") {
    inputElems[2].parentNode.style.display = "inline";

    inputElems[0].placeholder = "Area code";
    inputElems[0].pattern = "[0-9]{3}";

    inputElems[1].placeholder = "First part";
    inputElems[1].pattern = "[0-9]{3}";
    inputElems[1].setAttribute("aria-label", "First part of number");

    inputElems[2].placeholder = "Second part";
    inputElems[2].pattern = "[0-9]{4}";
    inputElems[2].setAttribute("aria-label", "Second part of number");
  } else if (selectElem.value === "UK") {
    inputElems[2].parentNode.style.display = "none";

    inputElems[0].placeholder = "Area code";
    inputElems[0].pattern = "[0-9]{3,6}";

    inputElems[1].placeholder = "Local number";
    inputElems[1].pattern = "[0-9]{4,8}";
    inputElems[1].setAttribute("aria-label", "Local number");
  } else if (selectElem.value === "Germany") {
    inputElems[2].parentNode.style.display = "inline";

    inputElems[0].placeholder = "Area code";
    inputElems[0].pattern = "[0-9]{3,5}";

    inputElems[1].placeholder = "First part";
    inputElems[1].pattern = "[0-9]{2,4}";
    inputElems[1].setAttribute("aria-label", "First part of number");

    inputElems[2].placeholder = "Second part";
    inputElems[2].pattern = "[0-9]{4}";
    inputElems[2].setAttribute("aria-label", "Second part of number");
  }
};
```

The example looks like this:

This is an interesting idea, which goes to show a potential solution to the problem of dealing with international phone numbers. You would have to extend the example of course to provide the correct pattern for potentially every country, which would be a lot of work, and there would still be no foolproof guarantee that the users would enter their numbers correctly.

It makes you wonder if it is worth going to all this trouble on the client-side, when you could just let the user enter their number in whatever format they wanted on the client-side and then validate and sanitize it on the server. But this choice is yours to make.
```

div {
  margin-bottom: 10px;
  position: relative;
}

input[type="number"] {
  width: 100px;
}

input + span {
  padding-right: 30px;
}

input:invalid + span::after {
  position: absolute;
  content: "✖";
  padding-left: 5px;
  color: #8b0000;
}

input:valid + span::after {
  position: absolute;
  content: "✓";
  padding-left: 5px;
  color: #009000;
}
```

Technical Summary
-----------------

|  |  |
| --- | --- |
| **Value** |
 A string representing a telephone number, or
 empty
  |
| **Events** | `change` and
 `input` |
| **Supported common attributes** | `autocomplete`,
 `list`,
 `maxlength`,
 `minlength`,
 `pattern`,
 `placeholder`,
 `readonly`, and
 `size` |
| **IDL attributes** | `list`, `selectionStart`,
 `selectionEnd`, `selectionDirection`, and
 `value` |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | `select()`,
 `setRangeText()`,
 `setSelectionRange()` |
| **Implicit ARIA Role** |
 with no `list` attribute:
 `textbox` | with `list` attribute: `combobox` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # telephone-state-(type=tel) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* HTML forms guide
* `<input>`
    + `<input type="text">`
    + `<input type="email">`
* Compatibility of CSS properties


<input type="date"> - HTML: HyperText Markup Language

<input type="date">
===================

`<input>` elements of **`type="date"`** create input fields that let the user enter a date, either with a textbox that validates the input or a special date picker interface.

The resulting value includes the year, month, and day, but *not* the time. The time and datetime-local input types support time and date+time input.

Try it
------

The input UI generally varies from browser to browser; see Browser compatibility for further details. In unsupported browsers, the control degrades gracefully to `<input type="text">`.

Value
-----

A string representing the date entered in the input. The date is formatted according to Date strings format.

You can set a default value for the input with a date inside the `value` attribute, like so:

```html
<input type="date" value="2017-06-01" />
```

**Note:** The displayed date format will differ from the actual `value` — the displayed date is formatted *based on the locale of the user's browser*, but the parsed `value` is always formatted `yyyy-mm-dd`.

You can get and set the date value in JavaScript with the `HTMLInputElement` `value` and `valueAsNumber` properties. For example:

```js
const dateControl = document.querySelector('input[type="date"]');
dateControl.value = "2017-06-01";
console.log(dateControl.value); // prints "2017-06-01"
console.log(dateControl.valueAsNumber); // prints 1496275200000, a JavaScript timestamp (ms)
```

This code finds the first `<input>` element whose `type` is `date`, and sets its value to `2017-06-01` (June 1st, 2017). It then reads that value back in string and number formats.

Additional attributes
---------------------

The attributes common to all `<input>` elements apply to the `date` inputs as well, but might not influence its presentation. For example `size` and `placeholder` might not work. `date` inputs have the following additional attributes.

### max

The latest date to accept. If the `value` entered into the element occurs afterward, the element fails constraint validation. If the value of the `max` attribute isn't a possible date string in the format `yyyy-mm-dd`, then the element has no maximum date value.

If both the `max` and `min` attributes are set, this value must be a date string **later than or equal to** the one in the `min` attribute.

### min

The earliest date to accept. If the `value` entered into the element occurs beforehand, the element fails constraint validation. If the value of the `min` attribute isn't a possible date string in the format `yyyy-mm-dd`, then the element has no minimum date value.

If both the `max` and `min` attributes are set, this value must be a date string **earlier than or equal to** the one in the `max` attribute.

### step

The `step` attribute is a number that specifies the granularity that the value must adhere to, or the special value `any`, which is described below. Only values which are equal to the basis for stepping (`min` if specified, `value` otherwise, and an appropriate default value if neither of those is provided) are valid.

A string value of `any` means that no stepping is implied, and any value is allowed (barring other constraints, such as `min` and `max`).

**Note:** When the data entered by the user doesn't adhere to the stepping configuration, the user agent may round to the nearest valid value, preferring numbers in the positive direction when there are two equally close options.

For `date` inputs, the value of `step` is given in days; and is treated as a number of milliseconds equal to 86,400,000 times the `step` value (the underlying numeric value is in milliseconds). The default value of `step` is 1, indicating 1 day.

**Note:** Specifying `any` as the value for `step` has the same effect as `1` for `date` inputs.

Using date inputs
-----------------

Date inputs provide an easy interface for choosing dates, and they normalize the data format sent to the server regardless of the user's locale.

In this section, we'll look at basic and then more complex uses of `<input type="date">`.

### Basic uses of date

The simplest use of `<input type="date">` involves one `<input>` combined with its `<label>`, as seen below:

```html
<form action="https://example.com">
  <label>
    Enter your birthday:
    <input type="date" name="bday" />
  </label>

  <p><button>Submit</button></p>
</form>
```

This HTML submits the entered date under the key `bday` to `https://example.com` — resulting in a URL like `https://example.com/?bday=1955-06-08`.

### Setting maximum and minimum dates

You can use the `min` and `max` attributes to restrict the dates that can be chosen by the user. In the following example, we set a minimum date of `2017-04-01` and a maximum date of `2017-04-30`:

```html
<form>
  <label>
    Choose your preferred party date:
    <input type="date" name="party" min="2017-04-01" max="2017-04-30" />
  </label>
</form>
```

The result is that only days in April 2017 can be selected — the month and year parts of the textbox will be uneditable, and dates outside April 2017 can't be selected in the picker widget.

**Note:** You *should* be able to use the `step` attribute to vary the number of days jumped each time the date is incremented (e.g. to only make Saturdays selectable). However, this does not seem to be in any implementation at the time of writing.

### Controlling input size

`<input type="date">` doesn't support form sizing attributes such as `size`. Prefer CSS for sizing it.

Validation
----------

By default, `<input type="date">` doesn't validate the entered value beyond its format. The interfaces generally don't let you enter anything that isn't a date — which is helpful — but you can leave the field empty or enter an invalid date in browsers where the input falls back to type `text` (like the 32nd of April).

If you use `min` and `max` to restrict the available dates (see Setting maximum and minimum dates), supporting browsers will display an error if you try to submit a date that is out of bounds. However, you'll need to double-check the submitted results to ensure the value is within these dates, if the date picker isn't fully supported on the user's device.

You can also use the `required` attribute to make filling in the date mandatory — an error will be displayed if you try to submit an empty date field. This should work in most browsers, even if they fall back to a text input.

Let's look at an example of minimum and maximum dates, and also made a field required:

```html
<form>
  <label>
    Choose your preferred party date (required, April 1st to 20th):
    <input
 type="date"
 name="party"
 min="2017-04-01"
 max="2017-04-20"
 required />
    <span class="validity"></span>
  </label>

  <p>
    <button>Submit</button>
  </p>
</form>
```

If you try to submit the form with an incomplete date (or with a date outside the set bounds), the browser displays an error. Try playing with the example now:

Here's the CSS used in the above example. We make use of the `:valid` and `:invalid` pseudo-elements to add an icon next to the input, based on whether the current value is valid. We had to put the icon on a `<span>` next to the input, not on the input itself, because in Chrome at least the input's generated content is placed inside the form control, and can't be styled or shown effectively.

```css
label {
  display: flex;
  align-items: center;
}

span::after {
  padding-left: 5px;
}

input:invalid + span::after {
  content: "✖";
}

input:valid + span::after {
  content: "✓";
}
```

**Warning:** Client-side form validation *is no substitute* for validating on the server. It's easy for someone to modify the HTML, or bypass your HTML entirely and submit the data directly to your server. If your server fails to validate the received data, disaster could strike with data that is badly-formatted, too large, of the wrong type, etc.

Handling browser support
------------------------

Browsers that don't support this input type gracefully degrade to a text input, but this creates problems in consistency of user interface (the presented controls are different) and data handling.

The second problem is the more serious one; with date input supported, the value is normalized to the format `yyyy-mm-dd`. But with a text input, the browser has no recognition of what format the date should be in, and there are many formats in which people write dates. For example:

* `ddmmyyyy`
* `dd/mm/yyyy`
* `mm/dd/yyyy`
* `dd-mm-yyyy`
* `mm-dd-yyyy`
* `Month dd, yyyy`

One way around this is the `pattern` attribute on your date input. Even though the date picker doesn't use it, the text input fallback will. For example, try viewing the following in an unsupporting browser:

```html
<form>
  <label>
    Enter your birthday:
    <input type="date" name="bday" required pattern="\d{4}-\d{2}-\d{2}" />
    <span class="validity"></span>
  </label>
  <p>
    <button>Submit</button>
  </p>
</form>
```

If you submit it, you'll see that the browser displays an error and highlights the input as invalid if your entry doesn't match the pattern `####-##-##` (where `#` is a digit from 0 to 9). Of course, this doesn't stop people from entering invalid dates, or incorrect formats. So we still have a problem.
```

span {
  position: relative;
}

span::after {
  right: -18px;
  position: absolute;
}

input:invalid + span::after {
  content: "✖";
}

input:valid + span::after {
  content: "✓";
}
```

At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker.

Examples
--------

In this example, we create 2 sets of UI elements for choosing dates: a native `<input type="date">` picker and a set of 3 `<select>` elements for older browsers that don't support the native date input.

### HTML

The HTML looks like so:

```html
<form>
  <div class="nativeDatePicker">
    <label for="bday">Enter your birthday:</label>
    <input type="date" id="bday" name="bday" />
    <span class="validity"></span>
  </div>
  <p class="fallbackLabel">Enter your birthday:</p>
  <div class="fallbackDatePicker">
    <span>
      <label for="day">Day:</label>
      <select id="day" name="day"></select>
    </span>
    <span>
      <label for="month">Month:</label>
      <select id="month" name="month">
        <option selected>January</option>
        <option>February</option>
        <option>March</option>
        <option>April</option>
        <option>May</option>
        <option>June</option>
        <option>July</option>
        <option>August</option>
        <option>September</option>
        <option>October</option>
        <option>November</option>
        <option>December</option>
      </select>
    </span>
    <span>
      <label for="year">Year:</label>
      <select id="year" name="year"></select>
    </span>
  </div>
</form>
```

The months are hardcoded (as they are always the same), while the day and year values are dynamically generated depending on the currently selected month and year, and the current year (see the code comments below for detailed explanations of how these functions work.)
```

span {
  padding-left: 5px;
}

input:invalid + span::after {
  content: "✖";
}

input:valid + span::after {
  content: "✓";
}
```

### JavaScript

The other part of the code that may be of interest is the feature detection code — to detect whether the browser supports `<input type="date">`.

We create a new `<input>` element, try setting its `type` to `date`, then immediately check what its type is — unsupporting browsers will return `text`, because the `date` type falls back to type `text`. If `<input type="date">` isn't supported, we hide the native picker and show the fallback (`<select>`) instead.

```js
// Obtain UI widgets
const nativePicker = document.querySelector(".nativeDatePicker");
const fallbackPicker = document.querySelector(".fallbackDatePicker");
const fallbackLabel = document.querySelector(".fallbackLabel");

const yearSelect = document.querySelector("#year");
const monthSelect = document.querySelector("#month");
const daySelect = document.querySelector("#day");

// hide fallback initially
fallbackPicker.style.display = "none";
fallbackLabel.style.display = "none";

// test whether a new date input falls back to a text input or not
const test = document.createElement("input");

try {
  test.type = "date";
} catch (e) {
  console.log(e.message);
}

// if it does, run the code inside the if () {} block
if (test.type === "text") {
  // hide the native picker and show the fallback
  nativePicker.style.display = "none";
  fallbackPicker.style.display = "block";
  fallbackLabel.style.display = "block";

  // populate the days and years dynamically
  // (the months are always the same, therefore hardcoded)
  populateDays(monthSelect.value);
  populateYears();
}

function populateDays(month) {
  // delete the current set of <option> elements out of the
  // day <select>, ready for the next set to be injected
  while (daySelect.firstChild) {
    daySelect.removeChild(daySelect.firstChild);
  }

  // Create variable to hold new number of days to inject
  let dayNum;

  // 31 or 30 days?
  if (
    [
      "January",
      "March",
      "May",
      "July",
      "August",
      "October",
      "December",
    ].includes(month)
  ) {
    dayNum = 31;
  } else if (["April", "June", "September", "November"].includes(month)) {
    dayNum = 30;
  } else {
    // If month is February, calculate whether it is a leap year or not
    const year = yearSelect.value;
    const isLeap = new Date(year, 1, 29).getMonth() === 1;
    dayNum = isLeap ? 29 : 28;
  }

  // inject the right number of new <option> elements into the day <select>
  for (let i = 1; i <= dayNum; i++) {
    const option = document.createElement("option");
    option.textContent = i;
    daySelect.appendChild(option);
  }

  // if previous day has already been set, set daySelect's value
  // to that day, to avoid the day jumping back to 1 when you
  // change the year
  if (previousDay) {
    daySelect.value = previousDay;

    // If the previous day was set to a high number, say 31, and then
    // you chose a month with less total days in it (e.g. February),
    // this part of the code ensures that the highest day available
    // is selected, rather than showing a blank daySelect
    if (daySelect.value === "") {
      daySelect.value = previousDay - 1;
    }

    if (daySelect.value === "") {
      daySelect.value = previousDay - 2;
    }

    if (daySelect.value === "") {
      daySelect.value = previousDay - 3;
    }
  }
}

function populateYears() {
  // get this year as a number
  const date = new Date();
  const year = date.getFullYear();

  // Make this year, and the 100 years before it available in the year <select>
  for (let i = 0; i <= 100; i++) {
    const option = document.createElement("option");
    option.textContent = year - i;
    yearSelect.appendChild(option);
  }
}

// when the month or year <select> values are changed, rerun populateDays()
// in case the change affected the number of available days
yearSelect.onchange = () => {
  populateDays(monthSelect.value);
};

monthSelect.onchange = () => {
  populateDays(monthSelect.value);
};

//preserve day selection
let previousDay;

// update what day has been set to previously
// see end of populateDays() for usage
daySelect.onchange = () => {
  previousDay = daySelect.value;
};
```

**Note:** Remember that some years have 53 weeks in them (see Weeks per year)! You'll need to take this into consideration when developing production apps.

Technical summary
-----------------

|  |  |
| --- | --- |
| **Value** |
 A string representing a date in YYYY-MM-DD
 format, or empty
  |
| **Events** | `change` and
 `input` |
| **Supported common attributes** | `autocomplete`,
 `list`,
 `readonly`, and
 `step` |
| **IDL attributes** | `list`, `value`, `valueAsDate`,
 `valueAsNumber`.
  |
| **DOM interface** | `HTMLInputElement` |
| **Methods** | `select()`,
 `stepDown()`,
 `stepUp()` |
| **Implicit ARIA Role** | `no corresponding role` |

Specifications
--------------

| Specification |
| --- |
| HTML Standard # date-state-(type=date) |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* The generic `<input>` element and the interface used to manipulate it, `HTMLInputElement`
* Date and Time picker tutorial
* Date and time formats used in HTML
* Compatibility of CSS properties