{
  "id": "p_7i6WR4PSy_Dq7WZc",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_7i6WR4PSy_Dq7WZc",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "You are halfway through planning a new project when the question lands on your desk: which browser should your agent or backend build against, Google Chrome or Apple Safari? You expect an easy answer. Chrome is bigger, so it should win. Then you open the APIs.io comparison and find the two nearly tied.\n\nThe two providers ranked first on the Browser tag are the two you would guess. Google Chrome sits at 59.9 and Apple Safari at 59.5. That is a 0.4 gap, and both are about 35 points above the tag's mean of 24.4. You should be clear about what the number measures. A Kin Score covers the public API surface each company publishes. It does not rate the browser itself, and it does not rate the company.\n\nHere is where it gets odd for you. Safari wins four of the six facets and still loses the composite. It takes 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, which is spread across Google Cloud. If you only cared about getting started quickly, that would settle it.\n\nBut 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 because there is nothing for it to read. Chrome publishes 7 OpenAPI files, 7 Postman collections and 75 JSON Schemas. Safari has no machine-readable contract at all. That 68.4-point gap on one facet cancels out four losses. On the six facets alone it comes to 56.9 against 56.5, and the conditional layers add exactly +3.0 to each side.\n\nYou should also know what is behind those files. Part of the gap is simply what each company ships. The Chrome Policy API and the Google Chrome Customers API, with 71 operations, 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, Chrome DevTools MCP for Google and the Safari MCP server that WebKit introduced in the Safari 27 beta for Apple.\n\nNow the turn that matters most, because it is about the catalog's own record. The agent readiness numbers look decisive: Chrome scores 40.5 and is agent-ready, while Safari scores 12.3 and is agent-aware. Before you take that at face value, notice the credit. Each side gets one dimension from work done by API Evangelist, not by 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 belongs to the company. And one more caveat about timing: Chrome was rescored on 2026-11-11 with a +12.7 rising trend, while Safari was last scored on 2026-11-06, so the two numbers are a week apart in age. Neither company documents idempotency or reversibility, which is normal for this tag, where 2.8% of Browser providers show either one.\n\nSo you stop treating the score as a winner and start treating it as a map. 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. 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.\n\nWhat you take away is simple. A near-tie can hide two very different strengths, and one heavily weighted facet can outvote four others. Safari's composite is held down almost entirely by having no contract, and a JSON Schema for its content-blocking rules or its Web Push payloads would give contract quality something to read. Chrome's weakest facets come from documentation split across Google Cloud consoles, and one developer page listing every Chrome API with how to authenticate to it would close most of that 40-to-58-point gap. For your decision, you match the surface to the thing you are building.\n\nRead the original: https://apis.io/2026/11/12/google-chrome-vs-apple-safari-four-facets-lose-to-one-contract/",
  "title": "You pick a browser API for your agent, and the scores split in a way you didn't expect",
  "topics": [
    "kin-score",
    "browser-apis",
    "api-contracts",
    "agent-readiness"
  ],
  "published_at": "2026-11-12T18:51:09.516Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}