sjPlot turns regression output into publication-ready social science tables

One package covers the analyses a social science paper actually reports

The README describes sjPlot as a collection of plotting and table output functions for data visualization, and then does something unusual for an R plotting package: it enumerates the statistical models rather than the chart types. The list includes simple and cross tabulated frequencies, histograms, box plots, generalized linear models, mixed effects models, PCA and correlation matrices, cluster analyses, scatter plots, Likert scales, effects plots of interaction terms in regression models, and constructing index or score variables. That ordering tells you what the package is for. A general purpose plotting library would lead with chart geometry. sjPlot leads with the analysis, because the hard part in social science output is not drawing a bar chart, it is producing a table whose rows are model terms, whose coefficients are labelled meaningfully, and whose formatting is identical across a dozen models in the same paper. The README also notes that much more is covered than what that sentence enumerates.

It sits on top of ggplot2, which decides who owns the output

The dependency situation is stated in the citation section rather than hidden. The README says that since core functionality of the package depends on the ggplot package, you should consider citing that package as well, and it links to the ggplot2 page on CRAN. So the graphics are not reimplemented. Whatever sjPlot draws, it draws through ggplot2, and that has two consequences. The first is that you inherit ggplot2's theming and rendering behaviour, which means a sjPlot chart looks like every other ggplot2 chart in your project and can be themed the same way. The second is that a change in ggplot2 can change how sjPlot output looks. The repository listing also shows a NAMESPACE file and an R/ directory, which is the standard R package layout, alongside DESCRIPTION, tests/, vignettes/, man/ for the generated help pages, and inst/ for installed extras. The presence of a .lintr file and an .Rbuildignore suggests the package is linted and built with the usual R tooling rather than a bespoke setup.

Installing is either install.packages or a devtools snapshot

Two install routes are documented, and the difference matters because the CRAN version and the GitHub version can be far apart. For the stable release from CRAN you run one command in the R console.

install.packages("sjPlot")

For the latest development snapshot you use devtools and point at the GitHub repository.

library(devtools)
devtools::install_github("strengejacke/sjPlot")

The README frames the first as the official, stable release and the second as the latest development build, pointing you at the latest changes. If you are reproducing a published paper, the CRAN route is the one that matches what the author used. If you are chasing a bug fix, the development snapshot may have it. The documentation and vignettes are not in the repository README itself, they are hosted at strengejacke.github.io/sjPlot/, and the repository carries a _pkgdown.yml file, which is the configuration for that site, along with a vignettes/ directory that holds the source of the vignettes.

The release tags stop in 2018 even though the tree keeps moving

Here is the maintenance picture, and it needs care. The last push was on 2026-04-28, so the repository is receiving changes. The recent release list, however, ends much earlier: sjPlot 2.6.2 dated 2018-12-18, sjPlot 2.6.1 from 2018-10-15, and sjPlot 2.6.0 from 2018-08-23. So there are commits after the last tag, and a CRAN submission file sits at the top level of the repository alongside cran-comments.md and NEWS.md. The README carries a CRAN status badge, which means the package's CRAN standing is published as a badge rather than described in prose, and this README does not state which version is currently on CRAN. That combination, a moving development branch plus an old tag list plus a badge for CRAN status, is the situation of an actively edited package whose release history is not kept in the tags. For a package that people cite in papers, that matters, because the version string recorded in your analysis is the thing that makes a result reproducible.

Citing the package is a first class operation

The README handles citation with unusual care, which tells you something about the audience. It says that if you want or have to cite the package, use citation('sjPlot') for the citation information, and it supplies a DOI badge pointing at a Zenodo record. The Zenodo DOI is the mechanism that makes a specific version of the package citable in a paper, independent of whatever the CRAN version happens to be on the day you run your analysis. The same section then adds the dependency note about ggplot2. For a package whose output appears in the results section of peer reviewed work, that combination of a citable archive and a stated dependency is the responsible thing to have, and it is worth copying as practice for any R package you build for publication. The package is distributed under a licence the repository listing does not classify, and the licence field is listed as unknown, so the licence question needs checking against the package metadata on CRAN rather than assumed.

Where a general purpose alternative fits and where it does not

The obvious alternative is to skip the package and build the tables with ggplot2 plus your own theme and formatting code, or with a dedicated table package such as gt for layout. The difference in approach is who owns the decisions. A generic pipeline gives you full control over every column and every label, and it produces exactly the table your journal wants, but you write and maintain that code yourself for every model in every paper, and the formatting drifts between analyses. sjPlot takes the opposite position: it encodes the conventions of the field, so a frequency table and a mixed effects model come out looking like they belong in the same paper without you writing a formatter for either. The cost is that you are inside a package built for a specific literature, and the cost of escape is high when you need a table shape the package does not produce. For an interactive analyst who only wants a quick look at a model, the overhead of either route is probably unjustified. For someone writing a paper with twenty tables, the choice is between maintaining your own formatting layer and accepting the package conventions.

Editorial conclusion

Adopt sjPlot if you write up social science results in R and want the same table format across papers without hand tuning every model summary. Do not adopt it if you need current package support, because the most recent tag is sjPlot 2.6.2 from 2018-12-18 even though the last push was on 2026-04-28, and the CRAN status of the current tree is not stated in the README. Verify first by installing from CRAN with install.packages("sjPlot"), confirming the installed version against the release history, and checking that the ggplot2 version on your machine still renders the output the package produces.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. strengejacke/sjPlot on GitHub