DT turns an R data frame into a sortable, searchable DataTable

One function turns a data frame into a web table

DT is an R interface to the DataTables library, and it does one thing: it takes R data and displays it through the DataTables JavaScript library. The entry point is a function called datatable(), and the documentation is clear that this is not the data.table package, a distinction the project documentation spells out explicitly with a note not to be confused with the data.table package.

That confusion is real enough that the project documentation bothers to address it. The two names sound similar, the underlying models are completely different, and a search for either will surface the other. Anyone writing about this package or advising on it will run into the same question.

The audience is R users who want an interactive table in their output. The package topics list datatables, htmlwidgets, javascript, r-package and shiny, which is the useful summary of the scope: DT is an htmlwidget, it is meant for Shiny applications, and it is a bridge from R data to a JavaScript component rather than a new table implementation of its own.

The value proposition is that DataTables gives you sorting, searching, paging and column controls in the browser, and DT handles the plumbing of getting an R data frame into that component and back again for server-side processing. The alternative is writing that JavaScript yourself, or settling for a static table in your R Markdown output.

Installing from CRAN, or the development version through pak

Installation is the standard R package flow, and the documentation gives both a stable path and a development path.

# install from CRAN
install.packages('DT')

# or the development version if necessary
# install.packages("pak")
pak::pak('rstudio/DT')

# then try DT::datatable(iris) as a hello world example

The CRAN line is what most people want and it is the version with the widest testing behind it. The pak route points at the GitHub repository, so it gives you the current state of the main branch, which for a package in maintenance-only mode is where any unreviewed fixes would land first.

The hello world example in the same block is worth noting. DT::datatable(iris) is the whole smoke test, and it works because iris is already in every R installation. If that call renders a table in your RStudio viewer or your browser, the package and its JavaScript dependencies are working.

The full documentation lives at rstudio.github.io/DT/, and the documentation asks that questions go to StackOverflow with at least the tags r and dt rather than to GitHub issues. The distinction is stated plainly: use GitHub issues only if you want to file bug reports or feature requests.

Maintenance-only mode, stated in the readme rather than hidden

The most consequential sentence in the documentation is the one about maintenance. The project documentation says that due to limited resources, the package is currently in the maintenance-only mode, that the only priority is to fix important bugs, and that pull requests to implement new features or fix bugs are welcome but cannot be guaranteed to be reviewed or merged. The authors say they will try their best, and they thank you for understanding.

That is an unusually explicit statement, and it is the kind you should weigh before adopting a package rather than discovering later. It tells you three things at once: the binding will not gain features, the maintainers are not promising turnaround on your pull request, and the underlying DataTables library is the part that moves.

The release history is consistent with that. The tags are DT 0.34.0 from 2025-09-03, DT 0.33 from 2024-04-04 and DT 0.32 from 2024-02-19, and the last push was on 2026-05-18. So the package is still receiving pushes, and a new version appeared after a long gap, but the cadence is that of a maintained-but-frozen project rather than an actively developed one.

The practical consequence for an adopter is that your upgrade path is DataTables, not DT. A new DataTables release can change the behaviour of the table in your application without any change on the R side, and if you are on an older DT version the binding may not anticipate it. Pinning a version becomes a reasonable habit rather than an unnecessary one.

Three licence files at the root, which is worth reading carefully

The licence situation is where the repository layout gives the clearest signal, and it is a signal to slow down rather than speed up.

GitHub classifies the repository as a custom licence it cannot categorise, with a pointer to the LICENSE file. But the top-level repository entries show three separate licence documents: LICENSE, LICENSE.md and LICENSE.note. A single-package repository does not normally need three.

The names suggest what is going on. LICENSE is presumably the licence of the R package itself. LICENSE.md is likely a plain-language version of the same terms. LICENSE.note is the one that is doing work: it is almost certainly there to record that some bundled component, most likely the JavaScript library that DT serves to the browser, carries terms of its own that differ from the package's.

That is the standard situation for a package that ships or serves third party assets, and it is not a red flag in itself. It is a reason to read all three files rather than the one the badge points at. This is not legal advice, only a practical note that the permission you rely on is the union of several documents, and that a package whose JavaScript dependency is a separate project with its own licence is not covered by a single blanket grant.

The other root files worth knowing about are NEWS.md, which records the changes between versions, cran-comments.md, which is the file CRAN checks for the submitted version, and DESCRIPTION and NAMESPACE, the standard R package metadata. There is also a revdep/ directory, the reverse dependency check that CRAN runs to see which other packages depend on this one, and a vignettes/ directory for the long-form documentation.

Other R table packages, and the features the readme says DT keeps

The project points readers to a list of other packages for making tables, hosted in the R Markdown cookbook, and immediately adds the caveat that DT has a few unique features that are unlikely to be available in other packages. So the honest framing is that there are alternatives, and the recommendation is not that DT wins on every axis.

The trade-off is between breadth and specialisation. The other packages are general purpose and are the right answer for most cases, particularly when you want a static table in a knitted document and do not need interactivity. DT is narrower: it exists to expose the DataTables component, which means its feature set is exactly the feature set of that JavaScript library plus the R binding.

That is a real advantage in one direction and a real constraint in the other. If your requirement is a specific DataTables behaviour, an extension point, or the Shiny integration, there is no substitute because the thing you want is DataTables. If your requirement is simply a table, the alternatives are probably less work.

The Shiny part deserves emphasis, because that is where the topics list puts shiny. In a Shiny application, a datatable() output with server-side processing changes the shape of the application, because the browser asks for a page of rows and the server does the sorting and filtering in R. That interaction model is more than a styling choice, and it is the reason a Shiny team reaches for this package rather than writing a table component by hand.

How the package is tested and shipped

The badges at the top of the readme show the shape of the quality process. There is an R-CMD-check workflow badge, which is the standard R package check that CRAN requires, a codecov test coverage badge pointing at the main branch, and a downloads badge for the CRAN mirror.

The repository layout is the standard R package arrangement, with R/ holding the source, man/ the generated documentation, inst/ for installed assets such as the JavaScript, tests/ for the test suite, and vignettes/ for the long-form guides. There is also a tools/ directory, which in an R package usually holds helper scripts used during the build or check, and a .Rbuildignore file, which lists paths to exclude from the built tarball.

Two of these say something useful about the project. The codecov badge implies the test suite is instrumented for coverage rather than being a handful of smoke tests, and the presence of tests/ alongside a CRAN check badge means the package has to pass the same check that any submission to CRAN must pass.

The revdep/ directory is worth a second look for an adopter. Reverse dependency checks enumerate the packages that depend on DT and test them, which tells you how wide the blast radius is when a new DataTables release changes behaviour underneath the binding. It is also the mechanism by which breakage in DT surfaces as breakage in other packages rather than in your own application, and the project documentation mentions DT in the context of the Shiny and R Markdown ecosystem where that indirect dependency chain is long.

Editorial conclusion

DT suits an R or Shiny team that wants interactive tables with server-side processing and would otherwise write that JavaScript by hand, and that is willing to depend on a package its own maintainers describe as in maintenance-only mode. It is the wrong choice for a project that needs new features from the binding, since pull requests implementing new features are accepted but are not guaranteed to be reviewed or merged. Before adopting it, read LICENSE, LICENSE.md and LICENSE.note together, because the three files in the repository root suggest the package and its bundled assets do not all carry the same terms, and pin your version rather than tracking the CRAN release in a Shiny application where a DataTables upgrade can change the table behaviour underneath you.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rstudio/DT on GitHub