WebKit is an open-source browser engine that turns HTML, CSS and JavaScript into the pages a user sees and interacts with. Among browser technologies on the web, it is the engine that powers Safari on macOS and iOS, the system web views inside Apple apps, and a range of Linux and embedded browsers.
WebKit began in 2001 as a fork of the KHTML and KJS projects from the KDE desktop and was released publicly together with Safari. It is one of the three major engine families in use today, alongside Blink, which Google forked from WebKit in 2013, and Gecko, which powers Firefox.
How WebKit is built
WebKit is not a single program but a set of cooperating components. The most important are WebCore, which handles parsing, the DOM, style resolution, layout and painting, and JavaScriptCore, the engine that executes scripts. A thin API layer on top lets applications embed the engine without touching its internals.
The table summarizes the main components and their responsibilities.
| Component | Responsibility | Notes |
|---|---|---|
| WebCore | HTML and CSS parsing, DOM, layout, painting | Implements the rendering engine itself |
| JavaScriptCore | JavaScript parsing, interpretation and compilation | Also exposed as a framework for apps |
| WebKit API layer | Interface for embedding the engine | WKWebView on Apple platforms |
| Platform ports | Graphics, networking and input per system | Apple, GTK, WPE and others |
| Web Inspector | Developer tools for debugging pages | Built into Safari and ports |
Modern WebKit uses a multi-process architecture. A UI process draws the browser window, while each site runs in a separate web content process with restricted permissions, and networking and GPU work happen in dedicated processes. This split improves stability and forms the basis of the browser sandbox, because a compromised page process has very limited access to the system.
JavaScriptCore and its compilation tiers
JavaScriptCore executes code through several tiers of increasing optimization. Code starts in a fast-starting interpreter and moves to more aggressive compilers only when it runs often enough to justify the cost of compilation, a strategy shared in principle with V8 in Chromium.
The following table lists the tiers in the order a hot function passes through them.
| Tier | Role | Trade-off |
|---|---|---|
| LLInt | Low-level interpreter for first execution | Instant start, slowest execution |
| Baseline JIT | Simple machine code generation | Quick to compile, moderate speed |
| DFG JIT | Optimizing compiler using type feedback | Faster code, higher compile cost |
| FTL JIT | Most aggressive optimizing tier | Best throughput for long-running code |
When an optimized function meets a value type it did not expect, the engine performs deoptimization and falls back to a lower tier. Scripts that keep object shapes and value types stable and predictable therefore run faster in WebKit, just as they do in other engines.
WebKit compared with Blink and Gecko
All three engines implement the same web standards, yet they differ in governance, release cadence and the platforms they reach. Because Blink descends from WebKit, the two still share some concepts and older code, while Gecko has an entirely separate lineage.
| Aspect | WebKit | Blink | Gecko |
|---|---|---|---|
| Main browser | Safari | Chrome, Edge, Opera | Firefox |
| JavaScript engine | JavaScriptCore | V8 | SpiderMonkey |
| Origin | Fork of KHTML in 2001 | Fork of WebKit in 2013 | Netscape heritage |
| Release coupling | Mostly tied to OS updates | Roughly four-week cycle | Roughly four-week cycle |
| Main steward | Apple with outside contributors | Google with outside contributors | Mozilla |
A practical consequence of the coupling to operating system updates is that Safari users on older devices may keep an older engine version for years. Feature support must therefore be checked against the oldest iOS version a project supports, not only against the latest Safari release.
Where WebKit runs and why it matters
WebKit reaches far beyond Safari. Apple apps that display web content use WKWebView, Linux desktops use WebKitGTK, and set-top boxes, car dashboards and other devices use WPE WebKit, a port designed for embedded hardware without a full desktop environment.
On iOS and iPadOS, App Store rules long required every browser to use WebKit, so Chrome, Firefox and Edge on an iPhone rendered pages with the same engine as Safari. In the European Union, Apple has since allowed alternative engines under regulatory pressure, but in most markets WebKit remains the only engine on iOS. For web developers this means that testing in Safari covers nearly all iPhone traffic.
Common compatibility pitfalls in WebKit
Most WebKit-specific problems arise from differences in feature timing and default behavior rather than outright bugs. Developers who test only in Chromium are the ones most often surprised in production.
| Symptom | Likely cause | Recommended approach |
|---|---|---|
| Layout breaks only on iPhone | Viewport height and toolbar behavior | Use dynamic viewport units such as dvh |
| Feature works in Chrome only | API not yet shipped in WebKit | Feature detection with fallbacks |
| Styles need prefixed properties | Legacy -webkit- vendor prefixes | Use autoprefixing in the build step |
| Storage cleared unexpectedly | Intelligent Tracking Prevention limits | Avoid relying on long-lived client storage |
| Video does not autoplay | Strict autoplay policy | Muted, inline playback attributes |
- Test on real iOS devices or simulators, because desktop Safari does not reproduce every mobile behavior.
- Watch release notes for the WebKit version shipped with each OS update.
- Do not sniff the user agent to detect WebKit; detect the specific feature instead.
The idea in brief
A web page arrives as text and code. Something has to read that code and turn it into the colors, text and buttons on the screen. That something is the browser engine, and WebKit is the engine inside Safari.
Think of it as the kitchen behind a restaurant counter. The browser window is the counter you see, while WebKit is the kitchen that takes the recipe and prepares the dish. On iPhones, almost every browser uses this same kitchen, so how WebKit behaves decides how websites look for a very large number of people.
A practical scenario
A small agency launches an online booking form for a dental clinic. It looks correct in Chrome on the developers’ laptops, but patients report that the submit button disappears behind the toolbar on iPhones.
The developers reproduce the problem in an iOS simulator. The form used a container set to 100vh, and in WebKit on iOS that value ignores the expanding and collapsing address bar. They switch to the dynamic viewport unit dvh, add a fallback for older iOS versions, and confirm that a date picker they used is supported in the oldest iOS version in the clinic’s analytics.
After the fix, completed bookings from mobile devices recover to the level seen on desktop, and the agency adds Safari on iOS to its standard release checklist.