Konqueror and KHTML user agent
Konqueror is the KDE desktop's web browser, historically powered by the KHTML engine — the codebase Apple forked to create WebKit. Its user-agent string carries Konqueror and KHTML tokens. Understanding it explains why so many modern user agents still include a KHTML-derived token, and identifies genuine Konqueror traffic.
What this means
Konqueror is the file manager and web browser of the KDE desktop environment on Linux. Its original rendering engine, KHTML, is historically important: Apple forked it to build WebKit, which in turn seeded Blink (Chrome's engine). That lineage is why the KHTML-style token echoes through modern user agents.
Genuine Konqueror is now niche, and recent versions can use other engines, but the Konqueror name and the KHTML token remain the signals of the classic browser.
How it appears
A classic Konqueror user agent carries a Konqueror product token and a KHTML token, typically with a like Gecko compatibility phrase. Do not confuse this with the KHTML-like reference that appears inside WebKit and Chromium user agents — those are descendant tokens, not Konqueror.
Match on the Konqueror product token to identify the real browser, and treat the KHTML token elsewhere as lineage cruft. The string is a claim and can be copied.
- Konqueror product token plus a KHTML engine token
- KHTML is the ancestor of WebKit and, via WebKit, Blink
- The KHTML token in Chrome/Safari is descendant cruft, not Konqueror
How it appears in analytics and logs
A user agent carrying Konqueror and KHTML tokens indicates KDE's Konqueror browser, a niche but real desktop browser. The KHTML token in mainstream browsers is a descendant reference, not Konqueror itself.
Diagnostic use case
Recognise genuine Konqueror traffic and understand the KHTML lineage that explains the KHTML-like token in WebKit and Chromium user agents.
What WebmasterID can help detect
WebmasterID can distinguish genuine Konqueror traffic from the inherited KHTML-derived token present in WebKit and Chromium user agents, avoiding confusion in browser-family reporting.
Common mistakes
- Reading the KHTML token in a Chrome or Safari user agent as Konqueror.
- Assuming all Konqueror versions use the KHTML engine — recent ones may differ.
- Matching KHTML alone rather than the Konqueror product token for the real browser.
Privacy and accuracy notes
The Konqueror and KHTML tokens reveal only the browser family. They carry no visitor identity. WebmasterID reads them as coarse browser context.
Related pages
- Linux user agent tokens
Desktop browsers on Linux include an X11; Linux platform token, usually with an architecture marker such as x86_64. The token confirms a Linux desktop browser but rarely identifies the distribution, and Linux strings are also common among servers, headless tools, and bots, so context matters.
- User agent history and evolution
Modern user-agent strings are stuffed with historical tokens — Mozilla/5.0, AppleWebKit, KHTML, like Gecko, Safari — that no longer mean what they say. They accumulated as browsers copied each other's tokens to pass server-side sniffing. Understanding this history explains why today's strings are misleading and why feature detection and Client Hints are preferred.
- Safari user agent on iOS and macOS
Safari's user agent is built around WebKit and a Version token, and differs between macOS and iOS. A notable quirk is that iPadOS can present a desktop-class Safari user agent, which can make an iPad look like a Mac in logs. This page covers the pattern and the platform-specific behaviour.
- Privacy-first analytics
Keep niche browser families visible as coarse context.
Sources and verification notes
- KDE — KonquerorKonqueror is KDE's browser; KHTML is the ancestor engine of WebKit. Tokens described generally.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.