Firefox 32-bit Linux Support to End in 2026

[e2le]

Seems sensible. Only 2.6% of users (with telemetry enabled) are using 32-bit Windows while 6.4% are using 32-bit Firefox on 64-bit Windows[0]. 32-bit Linux might see more use however isn't included in the stats, only 5.3% of users are running Linux[1] and I doubt many enable telemetry.

Maybe they could also drop support for older x86_64 CPU's, releasing more optimised builds. Most Linux distributions are increasing their baseline to x84-64-v2 or higher, most Firefox users (>90%)[0] seem to meet at least x84-64-v2 requirements.

[0]: https://firefoxgraphics.github.io/telemetry/#view=system

[1]: https://firefoxgraphics.github.io/telemetry/#view=general

[pigeons]

That seems like a lot of people to abandon! Perhaps the right financial decision, I don't know, but that seems like a significant number of users.

[kstrauser]

I’d have to agree. I doubt there are that many (in relative terms) people browsing the web on 32-bit CPUs and expecting modern experiences. I’ve gotta imagine it would be pretty miserable, what with the inherent RAM limitations on those older systems, and I’m sure JavaScript engines aren’t setting speed records on Pentium 4s.

[darkmighty]

> Maybe they could also drop support for older x86_64 CPU's, releasing more optimised builds

Question: Don't optimizers support multiple ISA versions, similar to web polyfill, and run the appropriate instructions at runtime? I suppose the runtime checks have some cost. At least I don't think I've ever run anything that errored out due to specific missing instructions.

[arp242]

> 32-bit Linux might see more use

Probably less, not more. Many distros either stopped supporting 32bit systems, or are planning to. As the announcement says, that's why they're stopping support now.

[snackbroken]

Less than 2.6% of browser users (with telemetry enabled) are using Firefox. Should the web drop support for Firefox? Seems sensible. (I would hope not)

[3np]

I believe even Raspberry Pi4B and 400 are still only having first-class drivers for 32-bit?

Kiosks and desktops and whatnot on Raspis still on 32-bit and likely to have Firefox without telemetry.

[postepowanieadm]

What's the threshold for minority to be ignored?

[xorcist]

Why is it reasonable? I understand that it would be financially reasonable for a commercial endeavour, but isn't Firefox more like an open source project?

Debian supports MIPS and SPARC still. Last I checked OpenSSL is kept buildable on OpenVMS. Surely there must be a handful of people out there who cares about good old x86?

If your numbers are correct, there are millions if not tens of millions of Firefox users on 32-bit. If none of them are willing to keep Firefox buildable, there must be something more to it.

[RainyDayTmrw]

That's surprising. Why is there such a comparatively large number using 32-bit Firefox on 64-bit Windows?

[pavon]

The last release to support 32-bit x86 hardware for popular distros was:

  Distro       | Release | Support | Extended Support
  -------------|---------|---------|------------------
  SLES 11      | 2009-03 | 2019-03 | 2022-03 | 2028-03
  RHEL 6       | 2010-11 | 2019-08 | 2024-06 | 2029-05
  Arch         | 2017-11 | *Ongoing releases via unofficial community project
  Ubuntu 18.04 | 2018-04 | 2023-05 | 2028-04 | 2030-04
  Fedora 31    | 2019-10 | 2020-11 | N/A
  Slackware 15 | 2022-02 | Ongoing, this is the most recent release
  Debian 12    | 2023-06 | 2026-06 | 2028-06
  Gentoo       | Ongoing

By the time FireFox 32-bit is dropped, all the versioned distros will be past their general support date and into extended support, leaving Gentoo, Arch32, and a handful of smaller distros. Of course, there are also folks running a 64-bit kernel with 32-bit Firefox to save memory.

[neilv]

Seems reasonable by Mozilla, to me, given precedents like the new Debian release not doing 32-bit release builds.

And doing security updates on ESR for a year is decent. (Though people using non-ESR stream builds of Firefox will much sooner have to downgrade to ESR, or be running with known vulnerabilities.)

If it turns out there's a significant number of people who really want Firefox on 32-bit x86, would it be viable for non-Mozilla volunteers to fork the current ESR or main stream, do bugfixes, backport security fixes, and distribute that unofficial or rebranded build?

What about volunteers trying to keep the main stream development backported? Or is that likely to become prohibitively hard at some point? (And if likely to become too hard, is it better to use that as a baseline going forward with maintenance, or to use the ESR as that baseline?)

[niutech]

There are already 32-bit forks like Waterfox or Pale Moon.

[Arnavion]

>[Updated on 2025-09-09 to clarify the affected builds are 32-bit x86]

That's nice... When this was originally posted on 09-05 it just mentioned "32-bit support", so I'd been worried this would be the end of me using FF on a Microsoft Surface RT (armv7, running Linux).

[dooglius]

Does this mean they are deleting a bunch of code, or just that people will have to compile it manually? I'd imagine there is a lot of 32-bit specific code, but how much of that is 32-bit-Linux specific code?

[Night_Thastus]

I'm honestly surprised just about anything supports 32-bit these days.

It's fine to keep hosting the older versions for download, and pointing users to it if they need it. But other than that, I see 0 reason to be putting in literally any effort at all to support 32-bit. It's ancient and people moved on like what, well over a decade and a half ago?

If I were in charge I'd have dropped active development for it probably 10 years ago.

[niutech]

You forget about people reviving old 32-bit PCs by installing a lightweight 32-bit Linux on them and 32-bit apps use less RAM than 64-bit.

[waynesonfire]

That's what Google did with Chrome.

[ars]

32 bit Firefox doesn't work anyway. I had an old 32 bit Firefox and didn't change it when I switched to 64 bit installation (I didn't realize).

It crashed NON-STOP. And it would not remember my profile when I shut down, which made the crashes even worse, since I lost anything I was working on.

I finally figured out the problem, switched to 64 bit and it was like magic: Firefox actually worked again.

[capitainenemo]

I don't know if you can draw any good conclusions from that on a linux install. Seems just as likely that after your 64 bit install switch, 32 bit libraries it was depending on were missing.

Linux distros don't tend to be as obsessive at maintaining full 32 bit support as the Windows world.

A better test would be to fire up a 32 bit VM and see if Firefox 32 bit crashed there...

[bgirard]

Did you attach the debugger and see what it was crashing on?

From when I used to work on performance and reliability at Mozilla, these types of user specific crashes were often caused by faulty system library or anti-virus like software doing unstable injections/hooks. Any kind of frequent crashes were also easier to reproduce and as a result fix.

[fulafel]

What is the memory usage difference like?

[fulafel]

Here's an old comparison that shows a surprisingly big difference with 10 tabs: https://www.ghacks.net/2016/01/03/32-bit-vs-64-bit-browsers-...

[anthk]

OpenBSD I386 user there, atom n270. Anyone who says it's useless... Slashem, cdda:bn, mednafen, Bitlbee, catgirl, maxima+gnuplot, ecl with common lisp, offpunk, mutt, aria2c, mbsync, nchat, MPV+yt-dip+streamlink, tut, dillo, mupdf, telescope plus gemini://gemini.dev and gopher://magical.fish ... work uber fast. And luakit does okish with a single tab.

[kstrauser]

I think that validates Mozilla’s decision. “See, retro enthusiasts know enough to select alternatives. We’re not stranding them without computers.”

[Narishma]

Same hardware but I'm using NetBSD instead since Debian dropped 32-bit support.