Input type date format: dd/mm/yyyy, mm/dd/yyyy and what is sent

Why are there two formats?

A date field has a value and a display, and they are separate things. The value is fixed by the HTML standard: four-digit year, month, day, with hyphens, like 2026-11-06. That is what input.value returns and what the form sends. The display is whatever the browser decides suits the person looking at it.

That split is on purpose. A visitor in Ohio reads 11/06/2026 as November 6th, a visitor in Leeds reads it as 11 June. The browser shows each of them their own order, and your server gets one unambiguous string from both.

What decides the display? Our test

On 6 November 2026 we opened the same page in Chromium 153 three times, with the browser locale set to US English, UK English and German, and once more in the Chromium pane of a desktop app with the page marked lang="en-US" and the field marked lang="en-GB". The computer was a Mac whose region writes dates as day.month.year.

All four showed 06.11.2026, with dots. Neither the page's language, nor the field's lang attribute, nor the locale Playwright reported to the page changed it. Chromium followed the operating system's region setting. The empty field showed the placeholder dd.mm.yyyy in the same order. Even the error for a date after max used it: “Value must be 01.11.2026 or earlier.”

Other browsers and systems make their own choice, so a visitor on a phone set to the US will see a different order from the one you see. You can't test your way to one format, because there isn't one.

The value, on the other hand, was the same in all four runs: 2026-11-06, sent as visit_date=2026-11-06.

What happens if you set dd/mm/yyyy in code?

It is ignored. We set the value from JavaScript in four ways and only the standard one stuck:

• "06/11/2026": value stays empty
• "2026-11-6": empty, the day needs two digits
• "2026-02-30": empty, there is no 30 February
• "2026-11-06": accepted

For each rejected one Chromium wrote a warning to the console: The specified value "06/11/2026" does not conform to the required format, "yyyy-MM-dd". If a date you prefill from a database or a URL does not show up, look for that line. Convert the date to yyyy-mm-dd before you set value, or set valueAsDate with a Date object.

The same format applies to min and max. We set min="01/01/2026" and the browser ignored it: an earlier date still counted as valid. With min="2026-01-01" the same date was refused with “Value must be 01.01.2026 or later.”. Without min and max there is no limit at all. Some tutorials claim a default range of 1920 to 2120, but in our test 1850-06-01 and 9999-12-31 were both valid, so set the range you need, and check it on the server too.

How do you set today's date as the default?

Carefully, because the obvious one-liners use the UTC date. We set the browser to Los Angeles at 8 pm on 4 November. input.valueAsDate = new Date() filled in 2026-11-05, tomorrow, and so did new Date().toISOString().slice(0, 10). East of UTC the same code shows yesterday in the early morning.

new Date().toLocaleDateString("en-CA") gave the right 2026-11-04, because the Canadian English short date happens to be yyyy-mm-dd and it uses the visitor's own time zone. Use the same string for min to stop people from picking a past date.

// Today's date in the visitor's time zone, as yyyy-mm-dd
const today = new Date().toLocaleDateString("en-CA");   // "2026-11-04"
const visit = document.getElementById("visit");
visit.value = today;   // prefill
visit.min = today;     // and no past dates

// Both of these use the UTC date and can be a day off:
// visit.valueAsDate = new Date();
// visit.value = new Date().toISOString().slice(0, 10);

value, valueAsDate and valueAsNumber

A date field gives you the same day three ways. For 4 November 2026, value was the string "2026-11-04", valueAsDate a Date at midnight UTC that day, and valueAsNumber 1793750400000, the milliseconds since 1970. An empty field gave "", null and NaN. The number is handy for arithmetic: two fields set to 4 and 7 November were 3 nights apart after dividing the difference by 86,400,000.

Two traps follow from the midnight UTC part. Format valueAsDate without a time zone and a visitor west of UTC sees the day before: in Los Angeles new Intl.DateTimeFormat("en-GB").format(new Date("2026-11-04")) printed 03/11/2026, and with timeZone: "UTC" it printed 04/11/2026. That is why the code further down passes timeZone: "UTC". The second trap is typing. After two digits the value was "" (the field reports badInput until the date is complete), and while the year was typed the input events carried 0002-04-11, 0020-04-11 and 0202-04-11 before 2026-04-11. A React or Vue handler that reacts to every change sees all of them, so don't treat a year below 1000 as final.

How do you show dd/mm/yyyy anyway?

Several ways, from least to most work.

Leave it to the browser. This is usually the right answer. The visitor sees the order they are used to, the picker works on phones, and you get a clean value. If your customers are all in the UK, their browsers already show dd/mm/yyyy.

A placeholder doesn't help here. We put placeholder="dd/mm/yyyy" on a date field and the browser ignored it, still showing its own dd.mm.yyyy hint. Put any format hint in the label instead.

Show the date next to the field in your format. Keep type="date" and print the chosen day underneath with Intl.DateTimeFormat. In our test new Intl.DateTimeFormat("en-GB") turned the field's date into 06/11/2026. Adding the weekday, “Friday, 06/11/2026”, removes any doubt about which order the visitor saw. The code below does this.

Use a text field. type="text" with placeholder="dd/mm/yyyy", pattern="\d{2}/\d{2}/\d{4}" and inputmode="numeric" shows exactly what you want. You lose the picker and the date check. Our test field refused 6/11/2026 with “Please match the requested format.” and sent 06/11/2026 as date=06%2F11%2F2026. The pattern only checks the shape, so 31/02/2026 would pass it too. Your server then has to parse that string, and trust that nobody in the US typed the month first. If you want people to type only digits, a few lines of JavaScript can add the slashes as they go; ours turned 06112026 into 06/11/2026.

Use three fields for day, month and year when the date is far in the past, such as a date of birth. Nobody has to page back forty years in a calendar, the order is spelled out in the labels, and the form sends three plain values, dob_day=06&dob_month=11&dob_year=1990 in our test, which you join on the server. Typing also works in the native field: on a desktop you can click it and type the digits.

A date-picker library gives you a calendar that looks the same everywhere. flatpickr, for example, keeps the value it sends in dateFormat (Y-m-d by default) and shows a second, readable field when you set altInput: true with altFormat: "d/m/Y". Test any library with a keyboard and a screen reader, because the native field gets both for free. Old advice about browsers that don't support type="date" and fall back to a text box is mostly history: MDN's compatibility data lists it in Chrome since version 20, Firefox since 57 and Safari on the Mac since 14.1.

<label for="visit">Preferred date</label>
<input id="visit" type="date" name="visit_date" min="2026-11-07" required
       aria-describedby="visit-text">
<p id="visit-text" class="hint"></p>

<script>
  const input = document.getElementById("visit");
  const text = document.getElementById("visit-text");
  // Show the chosen day in the format your readers expect.
  // The value the form sends stays 2026-11-06 either way.
  const format = new Intl.DateTimeFormat("en-GB", {
    weekday: "long", day: "2-digit", month: "2-digit", year: "numeric", timeZone: "UTC",
  });
  input.addEventListener("input", () => {
    text.textContent = input.valueAsDate ? "You picked " + format.format(input.valueAsDate) : "";
  });
</script>

What does the server receive?

From a date field, always yyyy-mm-dd, and an empty optional field sends the name with nothing after it: start_date=. A datetime-local field adds the time after a T, meeting=2026-11-04T14:30. That is the good part: you never have to guess whether 03/11 means March or November. Our article on HTML input types lists what every other type sends.

Still check the string on your own server, because a request doesn't have to come from your form. The trap is impossible dates. JavaScript's new Date("2026-02-31") quietly became 3 March, and so did PHP's DateTime::createFromFormat("!Y-m-d", "2026-02-31"), so compare the parsed date with the original string. Python's date.fromisoformat() refused it with a ValueError.

// Node.js: accept only a real yyyy-mm-dd date
function parseDate(s) {
  if (!/^\d{4}-\d{2}-\d{2}$/.test(s)) return null;
  const [y, m, d] = s.split("-").map(Number);
  const date = new Date(Date.UTC(y, m - 1, d));
  // 2026-02-31 would roll over to 3 March; reject it
  return date.getUTCMonth() === m - 1 && date.getUTCDate() === d ? date : null;
}

// Python: date.fromisoformat(s) raises ValueError for "2026-02-31" and "06/11/2026"
// PHP: $d = DateTime::createFromFormat("!Y-m-d", $s);
//      if (!$d || $d->format("Y-m-d") !== $s) { /* invalid */ }

Dates in a form sent to Formgong

If you post the form to Formgong, the date arrives in your email and Telegram notification exactly as sent, 2026-11-06. Formgong's field checks (Settings, then Protection, then Field checks) can mark a field as a date. That check accepts yyyy-mm-dd, optionally with a time, and nothing else. So a date field passes it, and a text field filled in as 06/11/2026 fails it. If you went the text-field route, set that field's check to text instead of date.

A booking form often needs more than the date: a question about the slot, a reminder, a review afterwards. Formgong's help chat can answer questions on the same page, and its review requests can follow the visit, from the same account as the form.

Which format did your visitors see?

If a browser or phone showed you a date order we did not describe, or a value other than yyyy-mm-dd, tell us at support@formgong.com with the browser and the system language. We will add it to this page.