Browser engines compared: Blink, Gecko and WebKit

Chrome, Firefox and Safari each run a different engine. We ran the same feature checks and measurements in Chrome, Firefox and Playwright's WebKit build to see where they differ.

Check your own browser

These are ten of our CSS.supports() checks, run in the browser you are reading this in, next to what each test browser returned.

This browser looks like checking.

Feature support in this browser next to the three test browsers
Check	This browser	Chrome 156	Firefox 159	WebKit 26.0 build
Selector: ::scroll-marker	checking	Yes	No	No
Selector: ::-webkit-scrollbar	checking	Yes	No	Yes
Selector: :has()	checking	Yes	Yes	Yes
Forms: appearance: base-select	checking	Yes	No	No
Text: text-wrap: pretty	checking	Yes	No	Yes
Sizing: interpolate-size	checking	Yes	No	No
Sizing: -moz-available	checking	No	Yes	No
Colour: light-dark()	checking	Yes	Yes	Yes
Functions: if()	checking	Yes	No	No
Anchor positioning: anchor-name	checking	Yes	Yes	Yes

Which browser uses which engine

Blink: Chrome and Chromium, Edge, Opera, Brave, Vivaldi and Samsung Internet.
Gecko: Firefox on desktop and Android, and Thunderbird.
WebKit: Safari, Mail and the App Store.

Browsers on one engine can still be on different versions of it. Opera 139, from October 2026, runs Chromium 155, while the Chrome in our run was 156.

On the iPhone, App Store guideline 2.5.6 requires WebKit in apps that browse the web. Apple grants exceptions by entitlement in the EU from iOS 17.4 and in Japan from iOS 26.2. Everywhere else, Chrome and Firefox on an iPhone run WebKit, so Chrome on your laptop tells you nothing about Chrome on an iPhone. We read these pages on 8 November 2026.

Where feature support differs

We ran 113 checks: 59 through CSS.supports() and 54 through DOM and JavaScript feature detection. All three browsers gave the same answer on 63. Chrome and Firefox disagreed on 25, listed here. On 24 of those, Chrome said yes and Firefox said no.

CSS checks where Chrome and Firefox gave different answers
CSS.supports() check	Chrome 156	Firefox 159	WebKit 26.0 build
Selector: ::scroll-button()	Yes	No	No
Selector: ::scroll-marker	Yes	No	No
Selector: ::-webkit-scrollbar	Yes	No	Yes
Forms: appearance: base-select	Yes	No	No
Text: text-wrap: pretty	Yes	No	Yes
Text: initial-letter	Yes	No	No
Sizing: interpolate-size	Yes	No	No
Sizing: calc-size()	Yes	No	No
Sizing: stretch keyword	Yes	No	No
Sizing: -moz-available	No	Yes	No
Shapes: corner-shape	Yes	No	No
Functions: if()	Yes	No	No
Functions: random()	Yes	No	Yes
Layout: reading-flow	Yes	No	No

DOM and JavaScript checks where Chrome and Firefox gave different answers
Feature detection	Chrome 156	Firefox 159	WebKit 26.0 build
At-rule: @view-transition	Yes	No	Yes
At-rule: @function	Yes	No	No
HTML: speculation rules	Yes	No	No
File System Access pickers	Yes	No	No
WebUSB	Yes	No	No
WebHID	Yes	No	No
Web Bluetooth	Yes	No	No
EyeDropper	Yes	No	No
navigator.userAgentData	Yes	No	No
navigator.connection	Yes	No	No
Long animation frame entries	Yes	No	No

hanging-punctuation was the only CSS check that the WebKit build alone passed. A passing check shows the browser parses the value and says nothing about how well the feature works.

The WebKit column is not Safari

Playwright’s WebKit comes from WebKit’s main branch, and the same page says Playwright “doesn’t work with the branded version of Safari”. Ours ran on Windows and reported version 26.0. Its user agent claims a Mac while navigator.platform says Win32. Apple’s own notes list features this build reported as missing:

Features the WebKit build reported as absent that Apple's WebKit notes list for Safari
Feature	In this build	Listed by Apple for
Navigation API	No	Safari 26.2
Largest Contentful Paint	No	Safari 26.2
Event Timing (for INP)	No	Safari 26.2
scrollbar-color	No	Safari 26.2
WebGPU	No	Safari 26 beta
CookieStore	No	Safari 18.4
Web Push	No	Safari 16, macOS Ventura
overscroll-behavior	No	Safari 16 beta

Age can’t explain the Safari 16 rows, since this build reports 26.0. Playwright says features that depend on the platform vary by operating system, and points to WebKit on a Mac for the closest match to Safari. Read the WebKit column as what one Windows build reports. A Safari answer needs a real Mac or iPhone. If you only have Windows, start with Safari on Windows.

Dotted pixel art of a golden sunset with a dark cloud above a bright horizon.

Default form control sizes

With no CSS applied, a text input was 177 pixels wide in Chrome, 164.67 in Firefox and 152 in the WebKit build, all on Windows 11.

Default width and height of form controls in pixels
Control, width × height	Chrome 156	Firefox 159	WebKit 26.0 build
text input	177 × 21	164.67 × 22	152 × 22
date input	116.33 × 21.33	119.67 × 21	152 × 22
range input	129 × 16	160 × 20	129 × 20
select	62 × 19	69 × 22	65 × 28
textarea	168 × 36	151 × 38	146 × 38
button	54.55 × 21	50.82 × 22	51.41 × 25
checkbox	13 × 13	14 × 14	12 × 12

Chrome’s text input used Arial at 13.33 pixels, Firefox’s used MS Shell Dlg 2 at the same size, and the WebKit build used MS Shell Dlg at 13. Pinning the box removed every difference: with the rule below, all 16 control types we tried measured 200 by 40 in all three.

input, select, textarea, button {
  font: 16px/1.25 Arial;
  box-sizing: border-box;
  width: 200px;
  height: 40px;
  padding: 8px;
  border: 1px solid #000;
  margin: 0;
}

Text widths barely differ

We measured one 60-character sentence at 16 pixels. For the named fonts, Firefox stayed within 0.15 pixels of Chrome, and the WebKit build matched Chrome exactly. The generic families are where they split.

Width of the same sentence in pixels
Font	Chrome 156	Firefox 159	WebKit 26.0 build
Arial	432.22	432.32	432.22
Georgia	422.41	422.47	422.41
Verdana	492.52	492.67	492.52
Courier New	576.09	576	576.09
monospace	428.86	429	468.08
system-ui	425.38	425.3	385.67

In the WebKit build, system-ui came out at the same width as Times New Roman, and monospace was 39.22 pixels wider than in Chrome. Neither result says anything about Safari on a Mac.

Scrollbars and layout limits

These scrollbar widths come from visible windows, because headless browsers can hide scrollbars. Windows was left at its default scrollbar setting.

Width taken by a vertical scrollbar in pixels
CSS	Chrome	Firefox, overlay off	WebKit build
overflow: scroll	15	17	0
scrollbar-width: thin	10	8	0
::-webkit-scrollbar { width: 8px }	8	17	8

Firefox reported 0 by default and 17 with widget.windows.overlay-scrollbars.enabled off, so the same page can have 15, 17 or 0 pixels less room. Firefox ignored ::-webkit-scrollbar. All three passed the scrollbar-gutter check if you want to reserve the space.

Layout rounding and the height of very tall blocks in pixels
CSS	Chrome 156	Firefox 159	WebKit 26.0 build
width: 33.333px	33.328125	33.333328	33.328125
height: 17,000,000px	17,000,000	17,000,000	17,000,000
height: 18,000,000px	18,000,000	0	18,000,000
height: 1,000,000,000px	33,554,428	0	33,554,428

Blink and WebKit store layout in sixty-fourths of a pixel, and Gecko in sixtieths. A block 18 million pixels tall reported a height of 0 in Firefox, while Chrome and the WebKit build capped at 33,554,428. Virtual lists that size one very tall spacer element can hit this.

Date parsing

Times are in Oslo time, the test machine’s zone.

How new Date() read each string, in Oslo time
Input	Chrome 156	Firefox 159	WebKit 26.0 build
2026-11-08T10:00	8 Nov 2026, 10:00	8 Nov 2026, 10:00	8 Nov 2026, 10:00
2026-11-08 10:00	8 Nov 2026, 10:00	8 Nov 2026, 10:00	8 Nov 2026, 10:00
11-08-2026	8 Nov 2026, 00:00	8 Nov 2026, 00:00	Invalid Date
08.11.2026	11 Aug 2026, 00:00	11 Aug 2026, 00:00	Invalid Date

Chrome and Firefox read 08.11.2026 as 11 August, the US month order, and the WebKit build refused it. Pass ISO 8601 with the T and they agree. Don’t match on error text either: reading a property of null gave Cannot read properties of null (reading 'x') in Chrome and null is not an object (evaluating 'null.x') in the WebKit build.

What to do about it

Use @supports or CSS.supports() for each feature. Don’t read the user agent: this WebKit build claims to be a Mac.
Set font, box sizing, width and height on form controls yourself.
Test in Chrome and Firefox as a minimum, then Safari on a real device.
When two engines disagree, cut the page down with a reduced test case before you blame either one.

How this was tested

A script served one page from 127.0.0.1 and ran the checks in each browser on 8 November 2026, on Windows 11, at 1000 by 800 pixels.

Chrome 156.0.8078.80, headless with scrollbars left on, then with a window.
Firefox 159.0.1, headless, then with a window, on default preferences apart from the one scrollbar preference above.
WebKit 26.0 from Playwright 1.56.1, on Windows. This build is not Safari, and nothing here ran on a Mac or an iPhone.

The full output is available as raw JSON, including all 113 checks and every value above. The test script and this article were prepared with help from AI.

How this used to work

Chromium used WebKit until it announced Blink in April 2013. The Blink FAQ gives Chromium’s multi-process architecture as the reason, and the extra work of supporting it in a shared codebase. So advice written before 2013 that says Chrome and Safari behave the same is out of date.

Common questions

Is Playwright’s WebKit the same as Safari?

No. It is a build of the WebKit engine with Playwright’s patches, and on Windows it reported several features as absent that Apple lists for Safari.

Does Chrome on an iPhone use Blink?

Apple’s guideline 2.5.6 requires WebKit outside the EU and Japan, so there it doesn’t.

Do I still need to test in more than one engine?

Yes. Chrome and Firefox disagreed on 25 of our 113 checks and on most default form control sizes. See what to test.