Skip to content


WebKit’s Multi-Process Architecture


In order to safeguard the rest of the system and allow the application to remain responsive even if the user had loaded web page that infinite loops or otherwise hangs, the modern incarnation of WebKit uses multi-process architecture. Web pages are loaded in its own WebContent process. Multiple WebContent processes can share a browsing session, which lives in a shared network process. In addition to handling all network accesses, this process is also responsible for managing the disk cache and Web APIs that allow websites to store structured data such as Web Storage API and IndexedDB API: Diagram of WebKit2's multi-process architecture Because a WebContent process can Just-in-Time compile arbitrary JavaScript code loaded from the internet, meaning that it can write to memory that gets executed, this process is tightly sandboxed. It does not have access to any file system unless the user grants an access, and it does not have direct access to the underlying operating system’s clipboard, microphone, or video camera even though there are Web APIs that grant access to those features. Instead, UI process brokers such requests.

FIXME: How is IPC setup

FIXME: How to add / modify an IPC message