yadcf puts per-column filter widgets on DataTables tables

A column filter is a widget, and the plugin is a widget factory

yadcf is a jQuery plug-in that allows the user to easily add filter components to table columns, working on top of the DataTables jQuery plug-in.

The idea is narrow and the implementation is correspondingly large. A table that is already being sorted and paged by DataTables gets a filter control attached to each column, and the control type depends on what the column holds. A column of yes or no values gets a select, a column of free text gets a text input with a delay, a numeric column gets a range, a date column gets a date range, and a column that should be matched by fuzzy search gets an autocomplete.

The filter types listed are select input, multiple selection input, text input, autocomplete input using the jQuery UI Autocomplete widget with some enhancements, date input using the jQuery UI Datepicker widget with some enhancements, range of numbers, range of numbers with the slider widget, range of dates using the Datepicker widget or Bootstrap Datepicker, and a custom function.

So the plugin is less a filter and more a set of column-filter widgets with matching logic attached, and that is why the jQuery UI and Bootstrap widget dependencies are visible in the design rather than hidden.

The package is MIT licensed, JavaScript, with the single runtime dependency of jquery at 3.5.0 or newer, and the published files are the plugin script and its stylesheet, with the main entry point being jquery.dataTables.yadcf.js. The version in the package file is 0.9.6 and there are no GitHub releases. The author is Daniel Reznick.

Two APIs for the same thing, and you must pick one

The usage section shows the same filter configuration written twice, and the difference between the two forms is the single most important thing to get right when you start.

$(document).ready(function(){
  //Old datatable API (lowercase "D")
  $('#example').dataTable().yadcf([
    {column_number : 0},
    {column_number : 1, filter_type: "range_number_slider", filter_container_id: "external_filter_container"},
    {column_number : 2, data: ["Yes", "No"], filter_default_label: "Select Yes/No"},
    {column_number : 3, filter_type: "auto_complete", text_data_delimiter: ","},
    {column_number : 4, column_data_type: "html", html_data_type: "text", filter_default_label: "Select tag"}]);
  
  //New datatable API (capital "D")
  var myTable = $('#example').DataTable();
  
  yadcf.init(myTable, [
    {column_number : 0},
    {column_number : 1, filter_type: "range_number_slider", filter_container_id: "external_filter_container"},
    {column_number : 2, data: ["Yes", "No"], filter_default_label: "Select Yes/No"},
    {column_number : 3, filter_type: "auto_complete", text_data_delimiter: ","},
    {column_number : 4, column_data_type: "html", html_data_type: "text", filter_default_label: "Select tag"}]);
});

The old DataTables API has a lowercase d in dataTable and the filters are attached with a chained yadcf call. The new API has a capital D in DataTable, you keep the table in a variable, and you initialise with yadcf.init.

The configuration array is identical in both cases, and reading the two side by side makes the shared vocabulary concrete. `column_number` says which column the filter applies to. `filter_type` selects the widget, here a range_number_slider and an auto_complete. `data` supplies a predefined source of values for a select, in this case a Yes and No list for a column that is presumably boolean. `filter_default_label` sets the prompt text, so the select does not just say Select value. `text_data_delimiter` splits a delimited text column into its parts for the autocomplete. `column_data_type` and `html_data_type` together say the column holds HTML elements and that the text should be extracted from them. And `filter_container_id` places the filter outside the table, in an element identified by that id.

The parameter list continues well beyond these, with column_selector, custom_func, data_as_is, html_data_selector, filter_container_selector, omit_default_label and filter_reset_butt, and the documentation points to jquery.dataTables.yadcf.js for the detailed explanation of each.

An external API for driving filters from your own code

The set of external API functions is the part that separates this from a column filter widget library, and the descriptions are unusually enthusiastic about their scope.

exFilterColumn allows you to trigger a filter externally or programmatically, supporting all filter types, and it is described as perfect for showing a table with pre filtered columns. exGetColumnFilterVal lets you retrieve a column's current filtered value, again for all filter types. exResetAllFilters resets all filters externally, described as perfect for adding a reset all button to your page. exResetFilters resets specific filters, for resetting one or more of them. And exFilterExternallyTriggered triggers all the available filters, which should be used only when the externally_triggered option is used.

There is one more, and it is a hook rather than a command. initSelectPluginCustomTriggers lets you set any select jQuery plug-in initialise and refresh functions, with the jQuery selector passed to your defined function, described as great for integrating any jQuery select plug-in such as Selectize or MultiSelect.

That last one addresses a real problem with select widgets. The default select is a native dropdown, but most people want something better, and the usual answer is to swap in a plugin. Doing that with a filter plug-in means the filter has to know how to initialise and refresh the replacement, and this hook is the seam that lets you do it without patching the library.

The rest of the miscellaneous features support the same goal. Filter delay for text, range_number, range_date and range_number_slider filters, so typing does not fire a request per keystroke. Predefined data source for a filter as an array of strings or objects. mData support including deeply nested objects. The ability to place the filter in an external HTML element. Control of the matching mode with the possible values contains, exact and startsWith. Case sensitive filtering as an option. Changing the filter's default label and its reset button text. Defining how the values in a filter are sorted and the order in which they are sorted. And support for aoColumns with bVisible false.

The data sources it works with, and how the plugin reads a column

The support list for data sources is explicit: all data source, DOM, Javascript, Ajax and server-side processing, from 1.10.0 onwards.

That last case, server-side processing, is where a column filter plugin can easily fall apart. With server-side processing the browser holds only the current page of rows, so a filter widget that derives its options from the visible data would offer a list of values that changes as you page. The plugin's answer is the `data` parameter, the predefined data source for a filter as an array of strings or objects, which lets you supply the complete set of values independently of what is loaded.

The parsing side is equally specific. The plugin parses various types of columns: plain text, plain text with a delimiter, and one or more HTML elements with the ability to extract text, value or id from each HTML element.

That third case is the one worth understanding, because it is what makes a filter work on a column of rendered markup. A table cell containing a link or a badge holds HTML, and the filter needs a value to compare against, not the markup. The `html_data_type` option chooses between extracting the text, the value or the id from each element, and `html_data_selector` narrows which elements in the cell are considered.

The example pages cover each combination rather than one happy path. There is a DOM source example, DOM source with chosen and DOM source with select2, DOM with multiple columns and tables for 1.10.0, an AJAX source example, an AJAX mData example marked deep, a multiple tables example, a server side source example, DOM and Ajax multiple for 1.10, an externally triggered filters example and a cumulative filtering example.

The multiple tables and multiple columns support is worth noting, since it means the plugin maintains per-table state for the same column configuration, and a page with several tables does not need a separate initialisation per table.

DataTables 2 has a separate rewrite, and the branch layout shows it

The most important piece of news in the documentation is at the top, and it changes the adoption calculus.

The author has started working on yadcf2 to support the new DataTables 2, with new demo pages at yadcf.web.app, and yadcf 2 will support DT 1 and DT 2, and you should use the yadcf.init api to init the filters.

So there are two lines of work. The current release, the one in the package file at 0.9.6, supports DataTables 1.10.0 and uses the API shown above. The next one will support both versions and standardises on yadcf.init.

The repository layout shows both of them. There is a src/ directory, a dist/ directory for the built output, and a top-level 2.0/ directory that is presumably where the DataTables 2 work lives. The 2.0/ directory being at the root rather than on a branch is a notable choice, since it means the rewrite is visible in the default branch and you can see which parts are still in flight.

The other top-level files are the working files of a classic jQuery plug-in. The main script is jquery.dataTables.yadcf.js, the stylesheet is jquery.dataTables.yadcf.css, and there is a bower.json and a yadcf.jquery.json for the jQuery plugin registry, which is how a plug-in of this era declares itself. There is a ChangeLog.markdown, an ISSUE_TEMPLATE.md, a contributing.md, an example.html and a package.json.

The last push was on 2026-07-11, the repository is not archived, and there are no GitHub releases, so the version to track is the npm one. Questions are asked on Stack Overflow with the yadcf tag, which for a plug-in of this age is often more useful than the issue tracker, since the questions get indexed and answered once.

Editorial conclusion

Adopt yadcf if you are already using DataTables 1 and want column filters without writing them, since the filter types, the reset buttons and the external API functions are the bulk of the work done for you. Skip it if you are on DataTables 2 and expect the current release to work, because the documentation says yadcf2 is the DataTables 2 rewrite and is a separate line of work. Verify first which DataTables version your page loads, whether your data source works with the filter types you need, and whether the browser matrix still matters to you, since the feature list claims support for all major browsers including IE8.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vedmack/yadcf on GitHub