How Do You Add Filtering and Sorting to a Webflow CMS List?

How Do You Add Filtering and Sorting to a Webflow CMS List?

Webflow's built in filters and sorts run at build time, not in the browser. They decide which items render when the page loads. If you want a visitor to click "Enterprise" and watch the list change, Webflow has no native feature for that. You need Finsweet Attributes or custom code.

This surprises people, and it surprises them late. A team scopes a resource hub with six filter categories, builds the Collection List, then opens the live site and finds the dropdowns do nothing. The filters were never for the visitor.

So this piece covers both halves: what the native settings genuinely do well, and what to reach for when you need real time filtering.

What Do Webflow's Native Collection List Filters Actually Do?

They query your CMS at build time and decide what appears. Webflow's Designer API reference for Collection List settings is clear that filters and sort rules are static settings applied at design and publish time. They determine which items render and in what order when the page loads.

That is genuinely useful. It is how you build a "Featured posts" section, a careers page showing only open roles, or a services grid that hides anything marked draft. The filter runs once, the HTML is generated, and the page is fast because there is nothing to compute in the browser.

What it is not is interactive. Webflow's own documentation states there is no native mechanism for site visitors to filter or sort a Collection List at runtime without custom code.

How Do Multiple Filters Combine?

With a setting called filterMatch, which takes one of two values. Set it to "all" and every filter rule must match, which is AND logic and the default. Set it to "any" and at least one rule must match, which is OR logic.

That one switch covers most of what teams need. "Published and featured" is all. "Tagged security or tagged compliance" is any. Mixing both kinds of logic in a single list is where you run out of road and start thinking about a different structure.

When we hit that wall, the usual fix is a boolean field on the collection that the editor sets directly. One switch called "Show on homepage" beats a clever four rule filter nobody else on the team can read.

Which Filter Rules Exist for Each Field Type?

They vary, and knowing them shapes how you model the collection. Plain text, email and phone fields support equals and doesNotEqual. Switch fields support isOn and isSet. Number and commerce price fields support equals, doesNotEqual, greaterThan and lessThan, with values passed as strings.

Reference fields use contains and doesNotContain with an item ID. Option fields take an option ID rather than the visible label. Date fields are the interesting one: you pass an object with an amount, a unit of days, weeks, months or years, and a direction of past or future. An amount of zero means today.

That date filter is quietly powerful. "Events in the next 30 days" or "posts from the past 7 days" becomes a single rule with no custom code, and it stays correct every time the site rebuilds. It is one of the reasons we plan date fields carefully during CMS modelling.

Can Filters Be Driven by Component Properties?

Some of them, yes. Certain filter values accept data source bindings, so one component can render different items depending on the property passed to it. The binding can point at a component prop, a CMS field, a page field, or locale values.

The operators that support bindings are equals and doesNotEqual on plain text, email and phone fields, the same four operators on number and commerce price fields, and the isSet and isOn operators. Option and reference filters must use static IDs and do not support bindings.

This is how you build one "related items" component and drop it on twenty pages, each showing a different slice. It is a real time saver, and it is the sort of thing we look for when deciding whether a section should be a component at all.

What Are the Limits on a Collection List?

The limit setting takes a value from 1 to 100, and passing null resets it to 100. There is an offset setting for skipping items, which also resets to zero when null. Pagination takes an itemsPerPage value that is rounded up and clamped between 1 and 100.

One constraint catches people out: pagination is only supported for dynamic Collection Lists connected directly to a CMS collection. Nested lists and some other arrangements cannot paginate, so the structure you choose early decides what is possible later.

The 100 item ceiling is the number to plan around. A directory with 400 entries cannot render as one list, which pushes you toward pagination, toward a search, or toward the approaches we describe in working with large Webflow CMS collections.

So How Do You Build Filtering the Visitor Can Use?

Finsweet Attributes is the standard answer, and it is the one we reach for most. It describes itself as an open source JavaScript library of solutions for adding filters, sort, load and search options to Webflow using simple HTML attributes. It is free, it is now on version 2, and Finsweet says the library sees over 200 million loads every month.

The relevant solutions are named plainly. List Filter handles filtering, List Sort handles sorting, List Load handles loading more items, and List Nest handles nested collection content. You add attributes to your existing Webflow elements rather than writing the logic yourself.

Worth knowing: Attributes v1, the legacy version, has been discontinued. If you inherit a Webflow site with old Finsweet attributes on it, that is a migration to plan rather than a thing to leave alone.

What Does This Cost You in Performance?

Runtime filtering means the browser is doing work the server used to do. The list renders, the script loads, and then the script hides and shows items based on what the visitor clicked. On a big list that is real main thread work on a real phone.

The honest trade is this: native filters give you fast pages and no interactivity. Attribute driven filters give you interactivity and a heavier page. Neither is wrong. What is wrong is adding a filter UI to a list of nine items because the design had one.

We ask one question before building any filter interface. If the list has fewer than about twenty items, a visitor can scan it faster than they can operate a filter, and we push back on the feature.

When Should You Use Search Instead?

When the categories are not obvious to the visitor. Filters work when people already know how your content is divided. Search works when they know what they want but not where you filed it.

A documentation site, a large blog archive, or a help centre usually wants search first and filters second. A pricing comparison or a small case study library wants filters, because the dimensions are few and meaningful.

Webflow has native site search on the relevant plans, which is often enough on its own. We go through the trade offs in our piece on Webflow site search.

What Would We Build on a New Project?

We start with native filters and no JavaScript, because that is the fastest page and the least to maintain. If the content model is right, a surprising number of "we need filtering" requirements turn out to be three separate pages with three different static filters, which is better for SEO anyway.

When a genuine multi dimension filter is needed, we use Finsweet List Filter with pagination or List Load, keep the item count per page modest, and make sure the unfiltered state renders in HTML so search engines and AI crawlers see the content without running scripts.

If you are planning a Webflow build with a filtering requirement and you are not sure whether it needs to be interactive at all, we are happy to talk it through before it becomes a scope problem. You can find us at phoenix.studio.