It's obviously not ready yet, but it's also not "infinitely far" anymore. I'm donating to them, because I think that they're the only realistic successor to the dying Firefox.
Mozilla Firefox merged Servo's Stylo CSS engine into Firefox 57 in 2017 and their WebRender renderer into Firefox 67 in 2019. I guess you could call that a "pretty niche browser" even then but that's a stretch.
No one's rushing to pick it up because Servo was originally an experimental Rust project meant to incrementally replace parts of Firefox. Then Mozilla stopped funding its development, and only recently have people picked it back up again as an independent browser implementation.
It was used to render the UI in apps like our favorite McAfee antivirus.
This niche is still wide open. Electron apps are just terrible, and a focused fast embeddable browser engine would be very welcome.
That's hardly a fair assessment when large parts of Servo were mainlined into Firefox years before Ladybird even existed. Stylo, their CSS engine, landed in Firefox 57 in 2017 replacing ~160k lines of C++ with ~85k lines of Rust.
Servo wasn't originally really intended as a browser competitor. It was the flagship experimental project of the Rust language to replace parts of Firefox with memory safe implementations, which it pulled off in style. It's only recently that people have picked it back up as a browser project, years after Mozilla killed the development.
Source: https://github.com/dioxuslabs/blitz
Status: https://blitz.is/status/css
Typical binary sizes are around 10-20mb, although you can go smaller by doing things like excluding features or compiling with `Os`/`Oz`.
There's no JavaScript yet (which can also be a benefit of course!), but people have recently started experimenting, and we may well start on this soon.
I agree with you but throwing web standards out the window like Sciter is a non-starter. One of the benefits of Electron apps is still having the option to run it in your browser.
> We are not ârewriting the browserâ. That's impossible. Put down the gun.
That kinda undersells it I think. It's really core components being ported: the JavaScript engine is already ported, with the style and layout systems underway.
It doesn't have to implement _all_ the standards, just a subset that is compatible with the full set. So that if you can develop an app within that subset and have it working in other browsers. But not necessarily vice versa.
Servo 0.4.0 contains all of the changes we landed in June, which came out to yet another record 558 commits (April: 534, May: 391). For security fixes, see § Security.
Weâve shipped several new web platform features:
sign(1em - 32px) (@Loirooriol, #45421)Plus a bunch of new DOM APIs:
This is another big update, so hereâs an outline:
Servo is steadily becoming a bigger and busier project every month, and by June 2026, weâve been reading through over four times the commits as we did when we started in September 2023.
This is hard work, particularly since there are things we need to know that are often difficult to answer just by reading the changes:
Who does the change affect, if anyone? Does it affect users, Servo developers, embedders, or some other group?
What observable difference does the change make, if any?
Does the feature require any preferences to be enabled, or is it enabled for everyone by default?
Are any real-world websites affected by the change?
What issue or broader project is the change related to? This question is answered by Fixes: #xxxxx or Part of: #xxxxx in the PR description.
Thanks to an initiative by @jdm, itâs now easier than ever for you to help us answer those questions, using the Servo Highfive bot! If youâre working on a pull request that you think might be interesting for the next monthly update, even if youâre not 100% sure, tell us about it by following the steps below:
You add the monthly update label to your pull request, or comment [@servo-highfive](https://github.com/servo-highfive) monthly update
Highfive posts a comment asking you some questions
You answer those questions in a comment containing [@servo-highfive](https://github.com/servo-highfive) monthly update answer
Servoâs JS runtime, SpiderMonkey 140.10.1, had several security bugs that have been fixed in Servo 0.4.0 with the update to SpiderMonkey 140.11.0 (@jschwe, #45584). For more details, see CVE-2026-8388, CVE-2026-8391, CVE-2026-8974, CVE-2026-8975, and MFSA 2026-48.
Several more security bugs in Servoâs JS runtime have been fixed in Servo 0.4.0 with the update to SpiderMonkey 140.12.0 (@jschwe, #45766). The exact CVEs that apply to us are not yet known, but for more details, see MFSA 2026-58.
RSA operations in SubtleÂCrypto now do modular exponentiation in constant time (@kkoyung, #45631). Please note that our RSA implementation is currently vulnerable to the Marvin Attack â for more details, see RUSTSEC-2023-0071.
ML-DSA operations in SubtleÂCrypto now do the Decompose step in constant time, fixing RUSTSEC-2025-0144 (@kkoyung, #45294).
Weâve fixed an HTML injection bug (XSS) in file:/// directory listings, which affected file names containing </script> (@sahvx655-wq, #45510).
Layout correctness has significantly improved on lichess.org, and many websites have become a lot more readable thanks to our improved handling of variable fonts (@simonwuelker, #45768), including Zulip (servo.zulipchat.com) and Speedtest (speedtest.net).
v0.3.0
v0.4.0

v0.3.0
v0.4.0

Zulip (servo.zulipchat.com)
v0.3.0
v0.4.0

Speedtest (speedtest.net)
Many websites worked in Servo even before version 0.4.0, including Google Photos (photos.google.com) and Cash Converters (cashconverters.com.au), and continue to work in version 0.4.0. Other websites, like Google Maps (maps.google.com) and OpenStreetMap (www.openstreetmap.org), render well but have some issues with interactivity.
Google Photos (photos.google.com)
Cash Converters (cashconverters.com.au)
Google Maps (maps.google.com)
OpenStreetMap (www.openstreetmap.org)
Weâre interested to hear how well your favourite websites run in Servo! Report successes in this Zulip thread, and failures in our GitHub issues.
Weâre implementing the more powerful version of âattr()â that can be used anywhere, not just in âcontentâ, under --pref layoutÂ_cssÂ_attrÂ_enabled (@Loirooriol, #45041, #45421, #45495, #45752).
WebGPU support has improved, under --pref domÂ_webgpuÂ_enabled:
All of the features above are enabled in servoshellâs experimental mode.
Weâve made more progress towards accessibility support, under --pref accessibility_enabled (@alice, @delan, #45555, #45554, #44949).
Weâve started implementing visible and interactive text selection (@mrobinson, @SimonSapin, #46107), one of the most long-awaited features of any web browser. Stay tuned!
Weâve also started working on Web Animations, under --pref domÂ_webÂ_animationsÂ_enabled (@simonwuelker, #45522, #45983), as well as webkitÂRelativeÂPath on File, under --pref domÂ_entriesÂ_apiÂ_enabled (@yezhizhen, #45666).
Rust doesnât have a stable ABI, so it has generally not been possible to embed Servo in another application without building Servo from source. To make it possible, weâve started designing a wrapper C API that will let you consume Servo as a prebuilt shared library using the stable and ubiquitous C ABI (@mukilan, #44984). Eventually the idea is that weâll create a wrapper Rust API around that wrapper C API, so you can have both the ergonomics of Rust and the build simplicity of C.
New in the Servo API:
Breaking changes:
WebÂView::sendÂ_error has been removed (@mukilan, #45502) â this method was always meant to be internal, and has become unused after we introduced the new WebÂView- and WebÂViewÂDelegate-based APIWeâve improved the docs for WebÂView, WebÂViewÂDelegate, JSÂValue, AlertÂDialog, AllowÂOrÂDenyÂRequest, AuthenticationÂResponse, BluetoothÂDeviceÂDescription, ConfirmÂDialog, ConsoleÂLogÂLevel, CreateÂNewÂWebÂViewÂRequest, EmbedderÂControl, EmbedderÂControlÂResponse, FileÂPicker, Image, JavaÂScriptÂErrorÂInfo, NavigationÂRequest, PermissionÂRequest, PixelÂFormat, PromptÂDialog, ProtocolÂHandlerÂRegistration, ProtocolÂHandlerÂUpdateÂRegistration, Scroll, SelectÂElement, SelectÂElementÂRequest, and WebÂViewÂVector (@mukilan, #45282, #45467).
In servoshell:
the Android version now requires Android 13+ (@jschwe, #46104)
the desktop version now lets you drag and drop files to open them (@simonwuelker, #45454)
the desktop version now lets the tab bar scroll horizontally if you have too many tabs open, but from one tab hoarder to another, maybe you should reconsider having so many tabs open (@Nylme, #44884)
the desktop version enters fullscreen on the monitor containing the window, even if youâve moved it to a different monitor (@rhit-kapilaar, #45556)
the desktop UI is more performant, resizes more smoothly, and no longer gets stuck in hovered states (@mrobinson, #45289, #45456, #45290)
and (@skyz1, #45705), CSS gradients (@mrobinson, #43945), âfont-styleâ and âunicode-rangeâ in â@font-faceâ (@Loirooriol, #45821), FontFaceSet (@mrobinson, #45390, #45382), HTMLÂInputÂElement (@steigeo, #45416), IntersectionÂObserver (@jdm, #45655, #45659, #45680), new Response() (@yezhizhen, #45953), URL.createÂObjectÂURL() and URL.revokeÂObjectÂURL() (@yezhizhen, #45182, #45417), and ECDSA and Ed25519 in SubtleÂCrypto (@kkoyung, #45833, #46017).
Weâve fixed bugs related to (@mrobinson, #45750), âanimation-delayâ (@yezhizhen, #45013), âclip-pathâ (@Loirooriol, #45468, #45373), âtab-sizeâ (@SimonSapin, @mrobinson, #45309), âwidthâ and âheightâ (@RichardTjokroutomo, #44627), âbox-shadow: insetâ (@Loirooriol, #45620), âanimationÂiterationâ events (@Loirooriol, #45990), âclickâ events (@mrobinson, #45751), âloadâ events (@jdm, #45883), âerrorâ events in Worker global scopes (@Gae24, #45829), and documentÂ.getÂElementÂByÂId() (@mrobinson, #45433).
We use a RefCell-based mechanism to store many of our DOM types in other DOM types, enforcing Rustâs âaliasing xor mutabilityâ rule at runtime by panicking if the rule is violated. But when garbage collection happens, we need to borrow() each DomRefCell to trace the references, and this is the source of many panic bugs. To fix that whole class of bugs, we initially created CanGc, a marker type that would annotate the code paths where GC can occur, in conjunction with custom static analysis (@jdm, #33140).
With the Rust type system we can do even better, if we flip that around and require any borrow_mut() call to prove that GC can not occur by passing a NoGC marker value. We can then require that a &NoGC must be borrowed from a &JSContext (which blocks GC) and not a &mut JSContext (which allows GC), taking advantage of how Rust references work without needing any custom static analysis.
We have a large codebase that needs to be migrated in parts, so for now weâve created the new method safeÂ_borrowÂ_mut() (@sagudev, #46050). We also need to update all of our script-related code to borrow our safe JSContext wrapper, rather than creating an owned JSContext on the spot.
This continues our long-running effort to use the Rust type system to make Servoâs integration with SpiderMonkey safer and more reliable (@Gae24, @Keerti707, @Narfinger, @TimvdLippe, @sagudev, @guptapiyush16, @ivomurrell, @kunalmohan, @skyz1, #45230, #45436, #45503, #45617, #45711, #45797, #45800, #45858, #45884, #45937, #45902, #45968, #45977, #45991, #46003, #46005, #46084, #45548, #45552, #45590, #45909, #45912, #45943, #46089, #46117, #46114, #45320, #45324, #45328, #45340, #45381, #45385, #45410, #45392, #45409, #45604, #45616, #45618, #45627, #45636, #45662, #45663, #45675, #45674, #45677, #45684, #45735, #45807, #45810, #45816, #45818, #45828, #45838, #45836, #45837, #45840, #45841, #45857, #45859, #45862, #45875, #45887, #45931, #45964, #45935, #45987, #45988, #46001, #46040, #46051, #46057, #46106, #46125, #45678, #46002, #45845, #45645, #45673, #45259, #45817, #45822, #45876, #45877, #45891).
NoGC was designed to prevent dynamic borrow failures, but it also enables some performance optimisations! If we can prove that garbage collection is impossible in some part of Servo, we can often avoid rooting JavaScript objects when interacting with them within that region of code. This has allowed us to reduce overheads by over 1% in the layout process and in HTMLÂCollection (@Narfinger, #46092, #45582).
Our memory usage has improved, with BoxFragment now 17% smaller (288 â 240 bytes on amd64) and ShapeCacheEntry now smaller too (@SimonSapin, @mrobinson, @simonwuelker, #45183, #45496).
Weâve fixed some nasty memory leaks when reloading and in 2D canvases (@Taym95, @sagudev, @jschwe, #45455, #45261, #45414).
Speaking of which, 2D canvases now use up to 23% less power (@yezhizhen, #45301), and we now avoid rasterising the same SVG more than once (@Narfinger, @jschwe, #44805).
Servo now decodes all images asynchronously and fills image caches asynchronously, leaving script threads (web content processes) more time for other work (@Narfinger, #45542, #44483). On top of that, weâve improved incremental layout (@mrobinson, @Loirooriol, #45411) and reduced reflows in IntersectionObserver (@jschwe, #45986).
Weâve started working on incremental updates for the stacking context tree, and as a side effect, weâve made some layout-bound microbenchmarks up to 10% faster (@mrobinson, @Loirooriol, #45208).
Weâve also reduced allocations, copies, GC rooting steps, and other operations in many parts of Servo (@Narfinger, @SimonSapin, @mrobinson, @Loirooriol, #45506, #45969, #45940, #45760, #46090, #45335, #45413, #45511).
For several months, FrĂŠdĂŠric (@fred-wang) has been fuzzing for Servo bugs, and thanks to his work weâve fixed sixteen (16) crash bugs in June, affecting