Google Chrome vs Apple Safari, four facets lose to one contract

Google Chrome vs Apple Safari, four facets lose to one contract

The two providers ranked first on the Browser tag are the two you would guess: Google Chrome at 59.9 and Apple Safari at 59.5. That is a 0.4 gap, and both sit about 35 points above the tag’s mean of 24.4. A Kin Score measures the public API surface each company publishes, not the browser itself and not the company. On that surface, Safari wins four of the six facets and still loses the composite. The rest of this post explains how.

The business. Neither company sells a browser, and both records list a freemium, self-serve access model. What they publish for developers is different. Chrome’s record lists nine features. Some are for building on the browser, such as Manifest V3 extensions, the DevTools Protocol and Web Store publishing. Others are Google Cloud services with Chrome’s name on them: enterprise device and policy management, the Chrome User Experience Report, Safe Browsing, PageSpeed Insights and Verified Access for ChromeOS. The record marks Chrome as open core, with an open-source project (Chromium) next to a commercial product. Safari’s record has no features recorded and describes Safari as Apple’s browser for macOS, iOS and iPadOS, with privacy at its center. On the security side Safari is the more documented of the two. It has four auth schemes, HSTS, a HackerOne program, Common Criteria, FIPS cryptographic-module validation and SOC 3. Chrome has one OAuth scheme with three scopes.

The APIs. Chrome has 16 API pages on apis.io and Safari has 9. The bigger difference is in the files behind those pages. Chrome publishes 7 OpenAPI files, 7 Postman collections and 75 JSON Schemas, for 98 artifact pointers in total. Safari has no machine-readable contract at all and 39 pointers. Part of that is just what the two companies ship. The Chrome Policy API and the Google Chrome Customers API (71 operations on chromemanagement.googleapis.com) are HTTP services. The Safari Web Extensions API, the Safari Authentication Services API and Apple Pay on the Web are JavaScript and native platform APIs, and no OpenAPI document could describe them. Both companies list an official MCP server. Google lists Chrome DevTools MCP, which lets coding agents drive and inspect a live Chrome. Apple lists the Safari MCP server that WebKit introduced in the Safari 27 beta.

The experience, facet by facet. Safari wins access clarity 100.0 to 42.1, discoverability 83.3 to 43.3, developer ergonomics 80.4 to 67.9 and operational transparency 76.3 to 63.2. Its documentation explains how to get started, where things are and what is running more clearly than Chrome’s spread across Google Cloud. Chrome wins two facets: contract quality 68.4 to 0.0 and contract governance 43.6 to 18.2. Contract quality carries the largest weight in the rubric, 0.25, and Safari scores zero on it because there is nothing for it to read. That 68.4-point gap on one facet cancels out four losses. On the six facets alone it is 56.9 against 56.5. The conditional layers add exactly +3.0 to each side, and both fall under the same horizontal regulatory regime, so the comparison is over the same set of facets. One caveat on timing: Chrome was rescored on 2026-11-11 with a +12.7 rising trend, and Safari was last scored on 2026-11-06. The two numbers are a week apart in age.

Agent readiness. This is where the two actually separate. Chrome scores 40.5 and is agent-ready. Safari scores 12.3 and is agent-aware. Chrome lights up spec presence, documented OpenAPI examples, a dry-run mode and served delegated identity. Safari has none of those, because those dimensions all read the contract Safari does not publish. Each side gets one dimension from work we did, and neither belongs to the company. Chrome’s agentic-access profile, 18 operations with 2 that take action, was derived by API Evangelist, and so were Safari’s three agent skills. Neither company documents idempotency or reversibility, which is normal for this tag: 2.8% of Browser providers show either one.

The verdict. Pick based on what you are building. If your agent or backend needs to call something over HTTP, such as managing a Chrome fleet, checking URLs against Safe Browsing or pulling CrUX field data, Chrome is the only one of the two with contracts, and its agent-readiness lead reflects that. If you are building for the web platform itself, like extensions, passkeys, push or payments in the browser, Safari’s surface is the easier one to read, find and start with, and its four facet wins show it. As for what would move each number: Safari’s composite is held down almost entirely by having no contract. A JSON Schema for its content-blocking rules or its Web Push payloads would give contract quality something to read. Chrome’s weakest facets, discoverability and access clarity, both come from its documentation being split across Google Cloud consoles. One developer page that lists every Chrome API with how to authenticate to it would close most of that 40-to-58-point gap.

← Solo.io Says MCP Authorization Belongs to Enterprise Identity
Lob's Checks API cancels a paper check only before it mails, and only on a paid edition →