WebKit: The Open-Source Browser Engine Behind Safari and iOS

What WebKit Is and Where It Runs

WebKit is a cross-platform web browser engine. On macOS and iOS, it powers Safari, Mail, Apple Books, App Store, and many other applications. It is also available on Linux through two ports: WebKitGTK, which integrates with the GTK toolkit and powers Epiphany (GNOME Web), and WPE, which targets embedded Linux devices without a traditional desktop environment.

The README describes WebKit as the infrastructure beneath these applications rather than a browser in its own right. Developers interact with WebKit by embedding it via its platform API, building one of the ports from source, or contributing to the engine code.

For macOS and iOS users who want to try the latest WebKit without building it, Apple provides Safari Technology Preview, linked from webkit.org/downloads/. On Linux, Epiphany Technology Preview serves the same purpose. On Windows, there is no prebuilt package; the README states plainly that Windows users have to build it themselves.

Repository Structure and Major Components

The WebKit repository is one of the largest open-source codebases in the browser engine space. The top-level layout reflects the scale of the project: Source/ holds the engine code, Tools/ holds build scripts and testing infrastructure, LayoutTests/ holds web platform conformance tests, JSTests/ holds JavaScript engine tests, PerformanceTests/ holds benchmarks, and WebKitLibraries/ holds third-party dependencies.

The engine is organized into multiple frameworks. JavaScriptCore (JSC) is the JavaScript engine. WebCore handles HTML parsing, the DOM, CSS layout, rendering, and web APIs. WebKit2 provides the multi-process browser architecture. Each has its own subdirectory under Source/.

The repository supports multiple platform configurations through cmake presets and build flags. The primary ports are the Apple port (macOS, iOS, tvOS, watchOS), GTK, and WPE. Each port has its own dependency installation scripts under Tools/gtk/ and Tools/wpe/. The build system uses both Xcode project files (for Apple platforms) and cmake with Ninja (for Linux and Windows).

The repository includes configuration files for multiple AI coding tools: .claude/, .codex/, and .gemini/ directories appear at the top level, indicating that the project has set up context files for several agent-based development environments.

Building WebKit on macOS

Building WebKit on macOS requires Xcode and its command line tools. The README lists three steps before building: install Xcode, install the Xcode Command Line Tools by running xcode-select --install, and install the Metal toolchain with xcodebuild -downloadComponent MetalToolchain.

Once prerequisites are in place, clone the repository and build:

git clone https://github.com/WebKit/WebKit.git WebKit

Then run the debug build:

Tools/Scripts/build-webkit --debug

Use --release for performance testing and other production-like scenarios. To test your local build with Safari, the run-safari script sets DYLD_FRAMEWORK_PATH to point to the build products before launching /Applications/Safari.app:

Tools/Scripts/run-safari --debug

To run other macOS applications with a local WebKit build:

Tools/Scripts/run-webkit-app <application-path>

For large repositories, git fsmonitor improves the speed of many git operations. The README recommends enabling it after cloning:

git config core.fsmonitor true

The repository also supports Xcode-based builds: open WebKit.xcworkspace and select the "Everything up to WebKit + Tools" scheme.

Building the GTK and WPE Ports on Linux

On Linux, WebKit is available as two ports. WebKitGTK integrates with the GTK display toolkit; WPE targets embedded systems and does not require GTK.

For a production GTK build:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
ninja
sudo ninja install

For a development GTK build with the dependency installation helper:

Tools/gtk/install-dependencies
Tools/Scripts/update-webkitgtk-libs
Tools/Scripts/build-webkit --gtk --debug

For WPE, the production build is similar with -DPORT=WPE:

cmake -DPORT=WPE -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
ninja
sudo ninja install

To run the MiniBrowser test application with a WPE development build:

run-minibrowser --debug --wpe

The README links to a separate wiki page at trac.webkit.org/wiki/BuildingGtk for more detail on GTK builds, and to docs.webkit.org/Ports/WindowsPort.html for the Windows port.

Who Actually Needs to Build WebKit

Most developers who work with WebKit do not need to build it from source. Web developers writing HTML, CSS, and JavaScript for Safari are using the version Apple ships with macOS and iOS, not a build from this repository. The -webkit- CSS vendor prefix is a browser API concern, not a build concern.

Building from source is relevant in narrower cases: engineers contributing changes to the engine, researchers testing browser security issues against the latest unreleased code, platform maintainers packaging WebKitGTK or WPE for a Linux distribution, and developers building custom embedded browsers on Linux using the WPE port.

The build time is substantial on all platforms. The Source/ directory contains millions of lines of C++, JavaScript, and Swift. A clean debug build on a modern Mac takes well over an hour. Incremental builds after a small code change are faster, but the initial setup cost is significant.

The repository's build scripts handle much of the platform-specific complexity, but they assume a correctly configured build environment that the README describes only at a high level. New contributors are pointed to webkit.org/contributing-code/ for the full onboarding path.

WebKit and Blink: Two Browser Engine Lineages

Blink is the browser engine used in Chrome, Chromium, Microsoft Edge, Opera, and most other non-Apple browsers today. Google forked Blink from WebKit in 2013, so the two engines share a common origin but have diverged significantly in architecture, rendering behavior, and JavaScript engine. Chrome uses V8 as its JavaScript engine, while WebKit uses JavaScriptCore.

The practical consequence for web developers is that behavior may differ between Safari and Chrome on some CSS properties, web APIs, and performance characteristics. This is especially visible in areas where WebKit implements a specification before Chrome, or where the two engines took different implementation paths. WebKit is the more restrictive of the two on certain privacy-related features, reflecting Apple's stated approach to user privacy in the browser.

For engineers choosing which engine to embed in a cross-platform application, the choice maps to platform: Apple platforms use WebKit through the system framework, Linux applications can choose WebKitGTK (GTK-based), Chromium Embedded Framework (Blink-based), or other options. There is no current official WebKit package for Windows with comparable first-party support to the Apple or Linux ports.

Filing Bugs, License, and Contribution Process

The last push to the repository was on 2026-09-27. There are no GitHub releases in the standard sense; WebKit is distributed as part of Apple's operating system releases and as Safari Technology Preview builds, not as standalone versioned releases on GitHub.

Bug reports go to WebKit's Bugzilla instance at bugs.webkit.org, not GitHub issues. The README describes the full bug filing procedure: search first for an existing report, create a Bugzilla account, and file against the WebKit product following the bug reporting guidelines. After filing, the reporter receives email updates as the bug progresses through its lifecycle.

The WebKit project's license is complex and not captured by a single identifier. The codebase mixes LGPL 2.1 (covering many of the core rendering components), BSD 2-clause, and other terms. The README does not summarize the license terms. Engineers who need to redistribute WebKit code, such as Linux distributors packaging WebKitGTK, should review the individual file headers rather than relying on any single top-level description.

Editorial conclusion

WebKit is relevant to three groups of engineers: those building browsers or embedded web views on Apple platforms, those maintaining Linux applications that embed web content via WebKitGTK or WPE, and those contributing to the engine itself. For everyone else, WebKit is invisible infrastructure. The build process is substantial on any platform and assumes Xcode on macOS or a configured cmake and Ninja environment on Linux. Windows users who need a prebuilt package will not find one; the README points to docs.webkit.org/Ports/WindowsPort.html for that path. File bugs against the engine using Bugzilla at bugs.webkit.org, not GitHub issues.

Frequently asked questions

Official sources

1. Issues
2. README
3. WebKit/WebKit on GitHub