Why iPhone Date Fields Stick Out of Forms That Look Fin...

On September 23, 2026, the owner of a small motel group sent me iPhone screenshots of their own booking page, some taken in Safari and some in the Chrome app. Every date field on the reservation form (date of birth, check in, check out, and the date beside the signature) ran past the right edge of the card the other fields sat in, stood taller than the text fields around it, and showed its value centered while everything else was left-aligned. I had looked at the same form in desktop Chrome and seen nothing wrong. We were both right, and the reason is the most useful thing I know about testing forms for phones: on an iPhone, the Chrome app is not the Chrome on your desk.

Desktop Chrome was the wrong witness

My first look proved nothing, for a dull reason. The desktop Chrome window I thought I had narrowed never actually got down to phone width, so I never saw the phone layout at all. When I measured properly later, in Playwright's Chromium at every width from 320 to 768 pixels, the date fields still sat exactly inside their card. The only difference Chromium showed was 2 extra pixels of height on each date field. Desktop Chrome wasn't hiding the bug. It doesn't have it, because the bug isn't in the page's CSS alone. It comes from code that only runs on iPhones and iPads.

Every browser on an iPhone is WebKit

Apple's App Review Guideline 2.5.6 reads: "Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript" (Apple). Google says it in its own documentation: "On iOS and iPadOS, Chrome uses WebKit as its rendering engine" (Chrome for Developers). Mozilla's docs say Firefox for iOS "doesn't use Gecko" (Firefox source docs). The browsers built into Instagram, Facebook and every other app live under the same rule. So the owner's Safari screenshots and Chrome screenshots showing the same broken fields weren't a coincidence. They were one engine photographed twice.

There are two exceptions on paper. Since iOS 17.4, apps may use another engine for users in the EU (Apple), and since iOS 26.2 in December 2025, in Japan (Apple Newsroom), each behind an entitlement with security conditions. As of September 2026, no major browser ships its own engine on iOS in either region: Open Web Advocacy's June 2026 report describes a Blink prototype and says Apple's terms still keep vendors from porting their engines (Open Web Advocacy). For testing, treat an iPhone as WebKit no matter which icon your visitor tapped.

What iOS does to a date input after your CSS runs

WebKit is open source, so none of this needs guessing. I read it at one pinned commit of the main branch, and every link below points at that commit.

It draws the field as a button. RenderTheme::autoAppearanceForElement gives date, datetime-local, month, time and week inputs the MenulistButton appearance on iOS, the same family a <select> belongs to, where the Mac and Linux builds get a plain text field (RenderTheme.cpp):

if (input->isDateField() || input->isDateTimeLocalField() || input->isMonthField() || input->isTimeField() || input->isWeekField()) {
#if PLATFORM(IOS_FAMILY)
    return StyleAppearance::MenulistButton;
#else
    return StyleAppearance::TextField;
#endif
}

Then the theme edits your computed style. For that appearance, iOS runs adjustInputElementButtonStyle after the cascade (RenderThemeIOS.mm). Unless your width is a fixed, positive length, it estimates the widest date the control could display in the phone's own locale, in the field's own font, and sets that as the field's min-width. For a date input that's the medium style, like "Sep 30, 2026" in US English (LocalizedDateCache.mm). Then it sets box-sizing: content-box, and the function gives WebKit's own reason in a comment: "Enforce the width and set the box-sizing to content-box to not conflict with the padding." That padding is half an em on each side. The older iOS code linked above forces it over whatever you wrote. The newer copy of the function, in the refreshed form-control code current WebKit uses on iOS, adds it only where you set no padding yourself (RenderThemeCocoa.mm), so the padding you wrote stays.

Read that with an ordinary form stylesheet in mind. You wrote width: 100% and box-sizing: border-box so the padding sits inside the width. A percentage isn't a fixed length, so the floor applies, and your border-box is turned back into content-box. Now 100% is the width of the content alone, and the padding and border are added on top. On this form the fields had 1rem of padding on each side, so with the border every date field ended about 35 pixels past its card, however wide the screen was.

It sets a minimum height. For a field whose height is automatic, adjustMenuListButtonStyle sets min-height to 20/11 of the font size, and never less than 15px: 29px at a 16px font (RenderThemeIOS.mm). Under content-box that minimum applies to the content alone, with padding and border stacked on top, which is why the date fields stood taller than the text fields next to them.

It centers the value. The iOS branch of WebKit's built-in stylesheet sets text-align: center on input::-webkit-date-and-time-value, next to the blue-text-on-gray-pill colors you may recognize (html.css). On iOS the value is one text box, not the separate month, day and year segments desktop engines draw (BaseDateAndTimeInputType.cpp). Two consequences: any ::-webkit-datetime-edit rules in your stylesheet do nothing on an iPhone, and an empty date field there shows no placeholder at all.

One declaration switches off the first three. RenderTheme::adjustStyle returns early when the used appearance is none, before it reaches the button adjustments (RenderTheme.cpp). With appearance: none, your width, padding, box-sizing and min-width stand as you wrote them. The native date picker still opens on tap, because the picker comes from the input's type, not from how it's painted. The centered value is a stylesheet rule, so it needs its own override.

This behavior changed in 2025, which explains some confusing advice you'll find. Until WebKit commit 292441@main in March 2025 (commit, bug 290080), iOS overwrote width itself with a fixed pixel value whenever yours wasn't one, so width: 100% was simply thrown away. The commit turned that into the min-width floor. Apple's release notes don't list it; from the timing it most likely reached iPhones in an iOS 18 update that spring, which is my inference, not Apple's statement. It's probably where the claim "iOS 18 fixed width: 100%" comes from. It didn't finish the job. The floor and the forced content-box are still in WebKit's main branch today, including in the newer form-control code, whose copy of the function opens with a FIXME saying it is a copy.

Reproducing an iPhone bug on a Windows machine

I worked this from a Windows box, with no Mac and no iPhone in reach. Playwright, the browser automation library, ships WebKit builds for Linux, Windows and macOS (Playwright repository), and its documentation is candid about them: they're built from WebKit's main branch with Playwright's patches, they aren't branded Safari, and "for the closest-to-Safari experience you should run WebKit on mac" (Playwright docs). None of those builds is iOS, so none of the code above runs in them. The iPhone device profiles set screen size, pixel ratio, touch and the UA header (Playwright emulation). That gets you a desktop engine at phone size, not a phone.

On Windows it was worse than that. Playwright's WebKit 26.4 build has no date control at all. With the iPhone 13 profile loaded, a field written as type="date" reported its type as "text". Out of the box, that build could never have shown me the owner's bug.

So I replayed the missing step. Before measuring, a short script finds every date input whose computed appearance isn't none and applies what the iOS theme would: min-width from the widest medium-style date, measured on a canvas in the field's own font; box-sizing: content-box unless the width is a fixed pixel length; min-height of 20/11 of the font size; and centered text. That's a model of the source code, not an iPhone, and I treat it as one. With it switched on, WebKit drew the owner's screenshots. At 390 pixels wide with 16px text, every date field ran 34.66 pixels past its card and stood 56.84 pixels tall beside 48.84-pixel text fields, value centered.

Then I ran it across everything: every page on the group's sites that carries a form, at six widths from 320 to 768 pixels, three text sizes, and four display states (light, dark, and each with high contrast). That's 3,816 page loads per engine, 3,744 of them on pages with date fields. WebKit with the replay failed all 3,744, with date fields 34.66 to 44 pixels past the card and 8 to 11 pixels taller than the text fields. Chromium failed none of them on width; its date fields were 2 pixels taller everywhere.

The same run turned up problems nobody had reported yet. On 2,995 of the 3,816 loads, in both engines, the page itself was wider than the screen. One cause alone, a footer row of links that didn't wrap, ran 69 pixels past a 390-pixel screen on every page of most of the sites. And at phone widths, the line of small print under the submit button slid behind a stack of floating buttons on the right edge, which the owner's screenshots had caught too.

What the replay can't tell me: how the picker behaves, whether a field zooms on focus, what the keyboard and Safari's toolbar do to the layout, or whether the value sits right vertically on a real device. Those need an iPhone. Without a Mac, the options are your own phone or a friend's, a paid cloud device service, or ios-webkit-debug-proxy over USB, which runs on Windows and whose README warns of "major discrepancies" between Chrome DevTools and the WebKit Inspector Protocol (GitHub). With a Mac, Xcode's iOS Simulator runs real iOS WebKit and Safari's Web Inspector attaches to it (Apple).

The fix

This is the date-field part of the CSS that went into the fix, with the site-specific selectors taken out. It goes after your own field styles.

input[type="date"],
input[type="time"],
input[type="datetime-local"],
input[type="month"],
input[type="week"] {
  -webkit-appearance: none; /* iOS before 15.4 only reads the prefixed form */
  appearance: none;         /* stops the iOS min-width, content-box and min-height step */
  display: block;
  box-sizing: border-box;   /* honored again once appearance is none */
  width: 100%;
  max-width: 100%;
  min-width: 0;
  text-align: left;
}

/* iOS centers the value in its built-in stylesheet, and an empty field
   collapses unless one line of height is reserved (WebKit bug 198959) */
input[type="date"]::-webkit-date-and-time-value,
input[type="time"]::-webkit-date-and-time-value,
input[type="datetime-local"]::-webkit-date-and-time-value,
input[type="month"]::-webkit-date-and-time-value,
input[type="week"]::-webkit-date-and-time-value {
  margin: 0;
  text-align: left;
  min-height: 1.2em; /* for engines without the lh unit */
  min-height: 1lh;
}

/* desktop engines pad the edit box a pixel or two; this is what made
   Chromium's date fields 2px taller */
input::-webkit-datetime-edit { padding: 0; }
input::-webkit-datetime-edit-fields-wrapper { padding: 0; }
input::-webkit-calendar-picker-indicator { padding-block: 0; margin-block: 0; cursor: pointer; }

/* a dark theme: draw the calendar icon light on the dark field */
[data-theme="dark"] input[type="date"] { color-scheme: dark; }

/* containers that refuse to shrink below their content */
form fieldset,
form .form-group,
form .grid > * { min-width: 0; }
form input, form select, form textarea { max-width: 100%; }

The unprefixed appearance arrived in Safari 15.4; the prefixed one has worked on iOS from the start, which is why both lines are there. Three other choices in that block need explaining.

The field's look isn't restated. The block sets geometry and nothing else. Every date field on those pages already carried the same class as the text fields, so once appearance: none took the iOS styling away, the date fields picked up the site's own padding, border, radius, background, font and colors in every display state. If your date inputs don't share your text fields' class, give them that class before you add this block, or you'll trade a pill for a bare box.

min-width: 0 on the field isn't enough alone. A flex item won't shrink below its content-based minimum size by default (CSS Flexbox), and a bare 1fr grid track means minmax(auto, 1fr) (CSS Grid), so the container needs the same treatment. On a small test form I wrote for this post, a two-column 1fr 1fr grid pushed the check-out field 77 pixels past a 320-pixel screen in Chromium, no iPhone required. Two-column grids on the real form got repeat(auto-fit, minmax(min(300px, 100%), 1fr)), so a column can never ask for more room than the form has.

display: block carries a known iOS risk. WebKit bug 139848, open since 2014, reports that display: block can leave a date input's value misaligned vertically (bug 139848). The workarounds are a height on the value, which the 1lh rule gives it, or keeping display: flex; align-items: center on the input. Check it on a phone either way. Bootstrap's .form-control ships the same core idea, appearance: none under a comment reading "Fix appearance for date inputs in Safari," plus a height on the value with a TODO to drop it once WebKit bug 198959 is fixed (Bootstrap source, bug 198959). Two projects landing on the same workaround is about as close to a second opinion as CSS gets.

The small print behind the floating buttons needed a separate fix: a right gutter at 600 pixels and below on the pages with forms, equal to the buttons' distance from the edge plus their 44-pixel width plus 6 pixels of air. The buttons weren't moved, resized or hidden. They're accessibility controls, and hiding them to make a form look tidy is the wrong trade. The footer row that pushed pages wider than the screen got flex-wrap: wrap at the same widths.

After the fix, the same 3,744 loads in both engines came back with no field past its box, date fields exactly as tall as the text fields, values on the left, and border-box sizing. Pages wider than the screen fell from 2,995 loads to 115, and all 115 are on one site, from a header problem this fix doesn't touch. At 1280 pixels, 64 desktop loads in the WebKit build matched element for element with and without the block, and in Chromium the date fields lost their 2 extra pixels. One thing the fix didn't reach: at 768 pixels, tablet width, the small print still runs under the floating buttons on 616 loads, because the gutter stops at 600 pixels.

What I haven't done yet is watch it on the owner's iPhone. Every number above comes from a WebKit build plus a model of iOS, and the phone gets the last word. If it disagrees, I'll update this post.

What else to check on an iPhone form

Text under 16 pixels zooms on focus: on an iPhone, not an iPad, WebKit zooms a focused field by 16 divided by its font size, so a 14px field zooms about 1.14 times (WKWebViewIOS.mm). The iOS built-in stylesheet gives inputs font: 11px system-ui, and form controls don't inherit your page font unless you tell them to (html.css), so an input you never styled zooms. Set input, select, textarea { font-size: 16px; }, or font: inherit with a 16px body.
maximum-scale=1 is the wrong fix for that zoom: Safari has ignored user-scalable for pinch zoom since iOS 10 (Apple), but in-app web views honor it unless the app opts out (Apple), Android Chrome honors it, and Lighthouse fails the page for it (Lighthouse). That takes zoom away from the people who need it.
100vh is taller than the screen you see: it equals the large viewport, measured with the toolbars retracted (CSS Values 4), so a full-height form can put its submit button under Safari's toolbar. Write min-height: 100vh; min-height: 100svh;; the small-viewport unit arrived in Safari 15.4 (WebKit).
Fixed bottom bars and the keyboard: when the keyboard opens, iOS Safari resizes only the visual viewport, so a position: fixed; bottom: 0 bar ends up behind the keyboard or floating mid-page (Chrome for Developers). The interactive-widget=resizes-content opt-out doesn't work in Safari (WebKit standards positions). Use the VisualViewport API, or don't pin actions to the bottom while a field has focus.
Safe areas: with viewport-fit=cover in your viewport meta, anything fixed to the bottom needs padding-bottom: max(12px, env(safe-area-inset-bottom)) or the home indicator sits on it (WebKit).
Floating widgets: chat bubbles, cookie bars and accessibility buttons cover the last field or the submit button on a 320 to 375 pixel screen. Reserve room for them, or collapse them while a field has focus.
Codes typed as numbers: type="number" on an iPhone brings up the regular keyboard on its numbers page rather than a number pad, unless pattern is exactly [0-9]* or \d* (WKContentViewInteraction.mm). For card numbers and one-time codes, GOV.UK's design system moved to <input type="text" inputmode="numeric" pattern="[0-9]*"> (GOV.UK).
A <select> with appearance: none loses the chevron iOS paints for it, so if you extend the fix to selects, draw your own arrow.

A checklist you can run against your own code

I turned all of this into a file you can use on your own site. It has the grep patterns for HTML and CSS, what to measure with pass and fail numbers for each, a Playwright script that checks four phone widths in WebKit and Chromium with the iOS replay built in and its limits written down, fix snippets, and a prompt you can hand an AI coding agent to audit a repository for the same problems.

webkit-iphone-form-checklist.md (opens in the browser) or save it directly.

The script exits with code 1 when a check fails, so it can sit in a CI job. On the small test form from the section above, it fails the broken version at every width in WebKit (date fields 34.66 pixels past their box and 9 pixels too tall, every field under 16px) and passes the fixed version in both engines.

What the Mega Analyzer checks

The Mega Analyzer has two rows for this, in the Perf + AI tab under Mobile presentation. The first finds the date, time, datetime-local, month and week inputs in your page's HTML and works out, from the CSS the page ships, whether an appearance: none wins on each one at phone width. It reads inline <style> blocks and the first two same-origin stylesheets, and when the page has date inputs, up to four more, including files on other domains and one level of @import. It fails a field only when your own CSS gives it a width, padding or border and every stylesheet the HTML links was read; if a file couldn't be read, the row says "not verified" and names it. The second row works out the font size of your text fields the same way and warns when one comes out under 16px, the size below which an iPhone zooms in on focus. That's as far as a check of static files can honestly go. The analyzer never loads your page as an iPhone, doesn't see CSS a script adds later, and can't see layout. A pass means the switch is in your CSS. The checklist's script and a real phone tell you whether the form looks right. If you suspect your server sends phones different HTML altogether, Mobile Parity compares what a desktop browser and Android Chrome are served.

When to leave it alone

The field has a fixed pixel width: the iOS theme skips the min-width and content-box step for a fixed, positive width. If that width fits your narrowest screen, the field won't overflow, although the value is still centered and the minimum height still applies.
You like the native pill and it fits: a date field left at its default width, on a line with room for it, can keep the iOS look. The fix is for fields that overflow or don't match their neighbors, not a verdict on Apple's style.
Your date fields are custom widgets: a JavaScript date picker built on a text input never gets the iOS date treatment, so this fix doesn't apply to it. It carries its own accessibility costs instead.
Don't swap out the native picker to escape this: appearance: none keeps the native picker, which is the accessible part of the control. Only the paint changes.

A booking form that works for the person who built it and not for a guest on a phone is the same species of bug as every "works on my machine" launch problem, and that gap is what The $97 Launch spends a chapter on.

Fact-check notes and sources

Source: https://developer.apple.com/app-store/review/guidelines/#2.5.6 establishes that iOS apps that browse the web must use WebKit, with entitlements for alternative engines in the EU and Japan.
Source: https://developer.chrome.com/docs/web-platform/blink establishes that Chrome on iOS and iPadOS uses WebKit as its rendering engine; https://firefox-source-docs.mozilla.org/overview/ios.html establishes that Firefox for iOS doesn't use Gecko.
Source: https://developer.apple.com/support/alternative-browser-engines/ and https://www.apple.com/newsroom/2025/12/apple-announces-changes-to-ios-in-japan/ establish the EU (iOS 17.4) and Japan (iOS 26.2) alternative engine rules; https://open-web-advocacy.org/blog/28-percent-faster--the-blink-prototype-that-shows-why-apples-ios-browser-engine-ban-must-end/ (June 18, 2026) establishes that vendors still had not shipped a ported engine. "No major browser ships its own engine on iOS" is an absence claim, current as of September 23, 2026.
Source: WebKit main at commit ae2aca5d8313f4aa421b26869a831de014e2bb0c, read September 23, 2026: RenderTheme.cpp lines 277 and 398 (appearance choice and the early return for none), RenderThemeIOS.mm lines 495 to 545 (min-width floor, content-box, min-height, and the older code's forced padding), RenderThemeCocoa.mm lines 3141 to 3200 (the newer copy, its comments, and padding added only where none is set), LocalizedDateCache.mm lines 100 to 128 (the date formats measured), html.css lines 405 to 424 and 476 to 520 (the 11px control font, the centered value), BaseDateAndTimeInputType.cpp line 376 (one text box on iOS), WKWebViewIOS.mm lines 1718 to 1768 (focus zoom), WKContentViewInteraction.mm lines 7456 to 7460 (number keyboards).
Source: https://commits.webkit.org/292441@main and https://bugs.webkit.org/show_bug.cgi?id=290080 establish the March 2025 change from an overwritten width to a min-width floor. The iOS release that first carried it is my inference from the dates.
Source: https://bugs.webkit.org/show_bug.cgi?id=198959 and https://bugs.webkit.org/show_bug.cgi?id=139848 establish the two open bugs behind the value height and alignment workarounds; https://github.com/twbs/bootstrap/blob/main/scss/forms/_form-control.scss establishes Bootstrap's matching workaround.
Source: https://playwright.dev/docs/browsers, https://playwright.dev/docs/emulation and https://github.com/microsoft/playwright/tree/main/browser_patches/webkit establish what Playwright's WebKit builds are and what device emulation sets. The type of a date input reading "text" in Playwright's WebKit 26.4 on Windows is my own measurement, September 23, 2026.
Source: https://github.com/google/ios-webkit-debug-proxy and https://developer.apple.com/documentation/safari-developer-tools/inspecting-ios establish the device inspection options with and without a Mac.
Source: https://www.w3.org/TR/css-flexbox-1/#min-size-auto and https://www.w3.org/TR/css-grid-1/ establish the automatic minimum size of flex items and of 1fr grid tracks.
Source: https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html, https://developer.apple.com/documentation/webkit/wkwebviewconfiguration/ignoresviewportscalelimits and https://github.com/GoogleChrome/lighthouse/blob/main/core/audits/accessibility/meta-viewport.js establish how Safari, in-app web views and Lighthouse treat zoom-blocking viewport settings.
Source: https://www.w3.org/TR/css-values-4/#viewport-relative-units and https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/ establish that vh is the large viewport and that small, large and dynamic viewport units shipped in Safari 15.4.
Source: https://developer.mozilla.org/en-US/docs/Web/CSS/appearance establishes browser support for appearance (unprefixed in Safari 15.4, prefixed on iOS from the first release).
Source: https://developer.chrome.com/blog/viewport-resize-behavior, https://github.com/WebKit/standards-positions/issues/65 and https://webkit.org/blog/7929/designing-websites-for-iphone-x/ establish the keyboard viewport behavior, the missing interactive-widget support in Safari, and safe-area insets.
Source: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/ establishes GOV.UK's move from type="number" to inputmode="numeric".
The before and after numbers (34.66 to 44 pixels of overflow, 8 to 11 pixels of extra height, 3,744 loads per engine, 2,995 and 115 over-wide loads) come from my own Playwright runs of WebKit 26.4 with the iOS replay and Chromium 147 on September 23, 2026. They are measurements of a model of iOS, not of an iPhone.

Why iPhone Date Fields Stick Out of Forms That Look Fine in Desktop Chrome