Why Apple Chose KHTML for the Safari Web Browser
In the early 2000s, Apple sought to create its own web browser to gain independence from Microsoft's Internet Explorer. After evaluating several existing rendering engines, Apple chose the KDE project's KHTML engine as the foundation for what would become WebKit and the Safari browser. This decision came down to four primary factors: KHTML’s remarkably small and clean codebase, its high rendering speed, its strong adherence to modern web standards, and a flexible open-source license that aligned with Apple's secretive development strategy.
The Need to Replace Internet Explorer
In 1997, Apple agreed to make Internet Explorer the default browser on Macintosh computers as part of a broader deal with Microsoft. By the early 2000s, this five-year agreement was ending. Internet Explorer for Mac was lagging in performance, and Microsoft was shifting its focus away from Mac software. Apple needed its own browser to ensure the future of the Mac platform and control the user experience on Mac OS X.
A Clean and Manageable Codebase
Instead of building a browser engine from scratch—which would take years—Apple’s engineering team, led by Don Melton, evaluated existing open-source engines. The most obvious candidate was Gecko, the engine behind the Mozilla project and Netscape.
However, Apple rejected Gecko because its codebase was massive, overly complex, and difficult to maintain. Gecko was built with its own cross-platform user interface toolkit, which Apple did not need since Mac OS X already had the Cocoa framework.
In contrast, KHTML (developed for the Konqueror browser on Linux) was compact and exceptionally well-written. It consisted of fewer than 150,000 lines of standard C++ code. Apple engineers could read, understand, and begin modifying the entire KHTML codebase in a matter of days, whereas mastering Gecko would have taken months.
Speed and Performance
Apple's primary goal for Safari was to make it the fastest browser on the Mac. Because KHTML did not carry the bloated legacy code of the 1990s browser wars, it was inherently lightweight. During Apple's internal testing, KHTML alongside its sister JavaScript engine, KJS, proved to be significantly faster at rendering web pages and executing scripts than its competitors. Its simplicity allowed Apple engineers to optimize it rapidly for Mac OS X.
Strong Web Standards Compliance
Despite its small size, KHTML was already a modern engine. It had robust support for HTML4, CSS1, and parts of CSS2, as well as the Document Object Model (DOM). Because the KDE developers had prioritized web standards from the beginning, Apple did not have to spend time rewriting the engine to support modern web design practices. They only needed to fix edge-case compatibility issues for websites that were coded specifically for Internet Explorer.
Favorable Open-Source Licensing
KHTML was licensed under the GNU Lesser General Public License (LGPL). This specific license was crucial for Apple's corporate strategy.
The LGPL allowed Apple to take the KHTML code, build a proprietary user interface (Safari) on top of it, and keep the entire project a secret until it was ready to launch. In January 2003, when Steve Jobs announced Safari at Macworld, Apple fulfilled its legal obligation under the LGPL by releasing their modified version of KHTML and KJS back to the open-source community as WebCore and JavaScriptCore, the foundational components of WebKit.