MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/d6d7ff2e2f9c

<input> elements of type month create input fields allowing a month and year to be easily entered.

The control's UI varies in general from browser to browser; at the moment support is patchy, with only Chrome/Opera and Edge on desktop — and most modern mobile browser versions — having usable implementations. In other browsers, the control degrades gracefully to a simple <input type="text">.

<input id="month" type="month">

For those of you not using a supporting browser, the Chrome/Opera month control looks like the below screenshot. Clicking the down arrow on the right hand side brings up a date picker to allow you to choose a date; you have to enter the time manually.

The Edge month control looks like this:

Value A DOMString representing a month and year, or empty.
Events change and input.
Supported Common Attributes autocomplete, list, readonly, and step.
IDL attributes value.
Methods select(), stepDown(), stepUp().

Value

A DOMString representing the value of the month and year entered into the input. You can set a default value for the input by including a date inside the value attribute, like so:

<label for="bday-month">What month were you both in?</label>
<input id="bday-month" type="month" name="bday-month" value="2017-06">

One thing to note is that the displayed date format differs from the actual value — the displayed date format will be chosen based on the set locale of the user's operating system, whereas the date value is always formatted yyyy-MM. When the above value submitted to the server, for example, it will look like bday-month=1978-06.

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

var monthControl = document.querySelector('input[type="month"]');
monthControl.value = '1978-06';

Using month inputs

Date-related inputs sound convenient at first glance — they provide an easy UI for choosing dates, and they normalize the data format sent to the server, regardless of the user's locale. However, there are issues with <input type="month"> because of the limited browser support.

We'll look at basic and more complex uses of <input type="month">, then offer advice on mitigating the browser support issue later on (see Handling browser support).

Basic uses of month

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

<form>
  <label for="bday-month">What month were you both in?</label>
  <input id="bday-month" type="month" name="bday-month">
</form>

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 are setting a minimum month of 1900-01 and a maximum month of 2017-08:

<form>
  <label for="bday-month">What month were you both in?</label>
  <input id="bday-month" type="month" name="bday-month"
         min="1900-01" max="2017-08">
</form>

The result here is that:

  • Only months between in January 1900 and August 2017 can be selected — months outside that range can't be scrolled to in the control.
  • Depending on what browser you are using, you might find that times outside the specified values might not be selectable in the time picker (e.g. Edge), or invalid (see Validation) but still available (e.g. Chrome).

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.

Controlling input size

<input type="month"> doesn't support form sizing attributes such as size. You'll have to resort to CSS for sizing needs.

Validation

By default, <input type="month"> does not apply any validation to entered values. The UI implementations generally don't let you enter anything that isn't a date — which is helpful — but you can still not fill in a date and submit, or enter an invalid date (e.g. the 32th of April).

You can use min and max to restrict the available dates (see anch("Setting maximum and minimum dates")), and in addition use the required attribute to make filling in the date 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 dates, and also made the field required:

<form>
  <div>
    <label for="month">What Month would you like to visit us? (Summer months only.)</label>
    <input id="month" type="month" name="month"
           min="2017-06" max="2017-09" required>
    <span class="validity"></span>
  </div>
  <div>
      <input type="submit" value="Submit form">
  </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'a screenshot for those of you who aren't using a supporting browser:

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 or not the current value is valid. We had to put the icons on a <span> next to the input, not on the input itself, because in Chrome the generated content is placed inside the form control, and can't be styled or shown effectively.

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;
}

input:valid+span:after {
  position: absolute;
  content: '✓';
  padding-left: 5px;
}

Important: 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 simply 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 is submitted (or data which is too large, of the wrong type, and so forth).

Handling browser support

As mentioned above, the major problem with using date inputs at the time of writing is browser support — only Chrome/Opera and Edge support it on desktop, and most modern browsers on mobile. As an example, the month picker on Chrome for Android looks like this:

Non-supporting browsers gracefully degrade to a text input, but this creates problems both in terms of consistency of user interface (the presented control will be different), and data handling.

The second problem is the most serious — as we mentioned earlier, with a month input the actual value is always normalized to the format yyyy-mm. With a text input on the other hand, by default the browser has no recognition of what format the date should be in, and there multiple ways in which people write dates, for example:

  • mmyyyy
  • mm/yyyy
  • mm-yyyy
  • yyyy-mm
  • etc.

One way around this is to put a pattern attribute on your month input. Even though the month input doesn't use it, the text input fallback will. For example, try viewing the following demo in a non-supporting browser:

<form>
  <div>
    <label for="month">What Month would you like to visit us? (Summer months only, yyyy-mm)</label>
    <input id="month" type="month" name="month"
           min="2017-06" max="2017-09" required
           pattern="[0-9]{4}-[0-9]{2}">
    <span class="validity"></span>
  </div>
  <div>
      <input type="submit" value="Submit form">
  </div>
</form>

If you try submitting it, you'll see that the browser now displays an error message (and highlights the input as invalid) if your entry doesn't match the pattern nnnn-nn, where n is a number from 0 to 9. Of course, this doesn't stop people from entering invalid dates, or incorrectly formatted dates that follow the pattern.

And what user is going to understand the pattern they need to enter the date in?

We still have a problem.

The best way to deal with dates in forms in a cross-browser way at the moment is to get the user to enter the month and year in separate controls (<select> elements being popular — see below for an implementation), or use JavaScript libraries such as jQuery date picker, and the jQuery timepicker plugin.

Examples

In this example we create two sets of UI elements for choosing dates — a native picker created with <input type="month">, and a set of two <select> elements for choosing months/years in older browsers that don't support the native input.

The HTML looks like so:

<form>
  <div class="nativeDatePicker">
    <label for="month-visit">What Month would you like to visit us?</label>
    <input type="month" id="month-visit" name="month-visit">
    <span class="validity"></span>
  </div>
  <p class="fallbackLabel">What Month would you like to visit us?</p>
  <div class="fallbackDatePicker">
    <div>
      <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>
  </div>
</form>

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

The other part of the code that may be of interest is the feature detection code — to detect whether the browser supports <input type="month">, we create a new <input> element, set its type to month, then immediately check what its type is set to — non-supporting browsers will return text, because the date type falls back to type text. If <input type="month"> is not supported, we hide the native picker and show the fallback picker UI (<select>) instead.

// define variables
var nativePicker = document.querySelector('.nativeDatePicker');
var fallbackPicker = document.querySelector('.fallbackDatePicker');
var fallbackLabel = document.querySelector('.fallbackLabel');

var yearSelect = document.querySelector('#year');
var monthSelect = document.querySelector('#month');

// 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
var test = document.createElement('input');
test.type = 'month';
// 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 years dynamically
  // (the months are always the same, therefore hardcoded)
  populateYears();
}

function populateYears() {
  // get the current year as a number
  var date = new Date();
  var year = date.getFullYear();

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

Specifications

Specification Status Comments
HTML Living Standard
The definition of '<input type="month">' in that specification.
Living Standard  

Browser compatibility

Feature Chrome Edge Firefox (Gecko) Internet Explorer Opera Safari
Basic support 20 12 No support[1] No support 10.62 No support[2]
Feature Android Chrome for Android Edge Firefox Mobile (Gecko) IE Mobile Opera Mobile Safari Mobile
Basic support (Yes) (Yes) (Yes) (Yes) ? (Yes) (Yes)

[1] This feature is not implemented yet. See bug 888320 and TPE DOM/Date time input types.

[2] It is recognized but there is no UI.

See also

Document Tags and Contributors

 Contributors to this page: chrisdavidmills
 Last updated by: chrisdavidmills,