Download websites that use JavaServer Faces

About JavaServer Faces

JavaServer Faces is old enough that finding it is itself a finding. First released in 2004 as part of the standard Java enterprise platform, it defined a component model for server rendered user interfaces: form state, validation, navigation and event handling managed on the server, with HTML produced as output rather than assembled in the browser. Maintenance now sits with Eclipse Foundation, where the specification continues as Jakarta Faces, which means the framework has already outlived several of the vendors that originally sold it.

Our taxonomy files the framework under Web frameworks, and that label is a poor fit worth flagging rather than hiding. Rendering happens on the server in Java, and the grouping reflects how our categories treat user interface frameworks in general rather than any claim about where the code runs. The category is best understood as a shelf label rather than as a technical description of the runtime.

What presence actually implies is a specific kind of organisation. Behind a page built with the framework there is a Java application server, an in house or contracted development team, a procurement cycle measured in years rather than sprints, and an application that was specified before single page front ends became the default. The sectors follow from that: banking, insurance, public administration, universities, utilities, healthcare administration and logistics. The pages themselves are usually portals, self service accounts, booking systems and internal applications with a public entrance, not marketing sites.

As of October 2026 we detect JavaServer Faces on 3,459 sites. Version information is recoverable on only part of that population, and where it can be read we record 3 distinct versions, with 2.0 the one recovered most often. A narrow version spread across an installed base of this age is informative in itself. Applications like these get patched rather than upgraded, because a framework migration means retesting a system that a regulator or an auditor cares about, so releases persist far longer than the vendor release notes would suggest.

Licensing reinforces the pattern. The implementation is available under Apache 2.0 terms, so a detected site is not a customer of anyone and no renewal ever lapses to force a decision. An application can sit unchanged for many years with nobody obliged to touch it, which is precisely why modernisation consultancies, application server vendors, security teams and staffing firms all want to know where the remaining deployments are.

Detection relies on artifacts left in the delivered HTML: framework resource paths, hidden view state fields and the URL suffixes the servlet mapping produces. Anything sitting entirely behind a login exposes none of that to a crawler, so the visible population is smaller than the real one and biased toward organisations that kept a public facing page on the stack. The list therefore reads as a floor, and the shape of it matters more than the total.

A per domain lookup tells you that one insurer runs the framework. The dataset answers the questions that only exist across a population: how many public sector portals in a given country still serve it, which top level domains concentrate it, what application servers and front end libraries sit alongside it, and whether the installed base is shrinking between snapshots or simply sitting still.