formattable keeps the numbers and changes only how they print

The problem with numbers that have to be turned into text

The package states its purpose plainly: it is designed for applying formatting on vectors and data frames to make data presentation easier, richer, more flexible and hopefully convey more information. The starting observation is about atomic vectors as the basic units to store data. Some data can be read more easily with formatting, and the example given is a numeric vector that stores a group of percentage numbers yet still shows in the form of typical floating numbers. The usual fix in R is to convert that vector to character, which solves the display and breaks everything else. Once the values are strings, arithmetic on them stops working, aggregation returns character results, and the column no longer joins or plots as a number. formattable takes the other route. It provides functions to create data structures with predefined formatting rules, so that these objects store the original data but are printed with formatting. The audience is therefore the person who has already tried format() on a column and found that the fix was worse than the problem.

Percent and accounting are numeric vectors with a print method

The core objects are vectors with pre-defined formatting rules and parameters, and the package ships several typical ones, percent, comma, currency, accounting and scientific. The percent example in the README is the clearest illustration of the design. You build a percent vector from c(0.1, 0.02, 0.03, 0.12), and it prints as 10.00% 2.00% 3.00% 12.00%. The README then states the key property in one line: the percent vector is no different from a numeric vector but has a percentage representation as being printed, it works with arithmetic operations and common functions and preserves its formatting. The demonstration adds 0.05 to the vector and gets 15.00% 7.00% 8.00% 17.00%, then calls max on it and gets 12.00%. So the format survives the operations rather than being applied to the result at print time. The accounting example makes the same point with a different flavour, since a balance of 1000, 500, 200, -150, 0 and 1200 prints as 1,000.00 500.00 200.00 (150.00) 0.00 1,200.00, with the negative in parentheses, and adding 1000 to it still prints with the accounting layout intact.

formattable() is the general case behind the special ones

The named types are special cases of a general function, and the general one is where the package earns its keep. formattable() applies highly customizable formatting to objects of a wide range of classes like numeric, logical, factor, Date and data.frame. The data frame example in the README shows what that means in practice. A data frame is built with an id column, a name column, a balance column created with accounting() and given a format argument of "d", a growth column created with percent() and also given format = "d", and a ready column. The README notes that a typical data frame may look more friendly with formattable column vectors. The important detail is where the formatting lives. It is attached to the column, not applied to a string version of the column, so the data frame keeps numeric columns and the print method renders them. The per column format argument is what makes this more than a set of pre-set types, and the wider class list is what makes it usable for the boolean, factor and date columns that every report has and that nobody wants to format by hand.

Installing from CRAN or straight from the repository

The package is available on both GitHub and CRAN, and the README gives the two routes. From CRAN the command is install.packages("formattable"), and it needs no extra tooling, which is what most users should do. From GitHub the README installs devtools first with a commented install.packages("devtools") line, then uses devtools::install_github("renkun-ken/formattable"). The README prints both snippets as syntax highlighted markup rather than plain code, so what you copy from the rendered page is the command with the surrounding HTML stripped away. The repository layout shows a conventional R package rather than a one file script. There is a DESCRIPTION file, a NAMESPACE, an R/ directory for the source, a man/ directory for the documentation, a tests/ directory, vignettes/, an inst/ directory, and a _pkgdown.yml that drives the documentation site. Two files are worth noticing. README.md is generated from README.Rmd on GitHub Actions, with a comment at the top of the generated file saying not to edit it by hand, so a contributor changes the Rmd source and the Markdown output is rebuilt. And there is a LICENSE file next to a LICENSE.md, with the licence field recorded as a custom one that GitHub cannot classify, so the terms are in those files and your own review should cover them if you ship the package inside a commercial product. The documentation is published under the package's own pkgdown site, and the README is also translated into Japanese, with README.ja.Rmd and README.ja.md maintained alongside the English original.

The formatting is for the console, and that is the boundary

The main limitation follows from the design, and it is worth being blunt about it. A formattable object stores the original data and prints it formatted, so the formatted representation is a property of printing, not of the value. If you write that object to a CSV, export it, pass it to a plotting function that expects plain numbers or hand it to another system, what travels is the underlying numeric data, not the percentage sign or the thousands separator. That is usually what you want, since it keeps the data honest, but it means the package is not a formatting engine for output artefacts. If you need a formatted string in a report file, you have to ask for it explicitly rather than assume the object carries it. The second limitation is the size of the catalogue. The shipped types are percent, comma, currency, accounting and scientific, and while formattable() is customizable, each custom format is a rule you write and maintain, and the README does not enumerate a full set of currency or locale aware formats, so a requirement that varies by country is on you. The third is the version picture. The only tagged release on record is v0.2.1 from 2021-04-21, the build badge points at an R Continuous Integration workflow and the repository also carries .travis.yml and appveyor.yml from an earlier era, and the last push was on 2026-10-10, so the code is being touched while the published version sits still. For a package on CRAN that is a normal pattern, but it means the CRAN version and the repository HEAD are not the same thing.

How it differs from format() and from the print-only approaches

The alternatives each solve a different part of the problem. The base R function format() converts a vector into a character vector, and it is the standard way to get a table to look acceptable, but the result is a character vector and everything numeric about it is gone. Rounding and reordering after that point is string work, which is where the bug reports come from. sprintf() gives you precise control over the string you produce, and is the right tool when you need exactly one number formatted a particular way for a label or a file, but it is a formatting function, not a data structure, so the value has to be carried separately from its display form. The other family of approaches is display time formatting in the output layer, where knitr, rmarkdown and the table packages format columns at render time and the data frame stays completely plain. That approach is arguably better for reports, since the format is a property of the document rather than of the data, and it separates the two concerns that formattable deliberately merges. The trade is the reverse. formattable makes the presentation decision once at the point where the data is created, and that decision then applies everywhere the object is printed, including the interactive console, which is where a lot of R work actually happens, and it applies to a bare vector, not only to a table in a document. If your team has a report pipeline that already handles formatting at render time, formattable adds a second mechanism rather than replacing one.

Editorial conclusion

formattable suits an R user producing printed tables and reports where a column of percentages or accounting figures currently has to be converted to character before it looks right, since the package keeps the underlying numeric values intact while changing the printed representation. It is the wrong tool if the output is destined for a machine, because the formatted values are for display and the underlying numbers are what a downstream consumer sees, and it is the wrong tool if you need formatting at render time in a document pipeline, where the format is a property of the output format rather than of the data. Before you adopt it, install the CRAN version with install.packages("formattable") and check the reference pages for the format you need, and read the NEWS file, because the newest tagged release on record is v0.2.1 from 2021-04-21 while the repository itself was pushed on 2026-10-10.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. renkun-ken/formattable on GitHub