caniemail: what each email client actually supports

A support table for the parts of CSS email clients break on

Can I email answers a narrow question that email developers keep asking: does this client support this feature. The site at caniemail.com provides email client support tables for HTML and CSS features, and the repository topics place it squarely in the email marketing and HTML email world.

The problem it addresses is real. Web standards documentation tells you what a feature is, not whether Outlook on a particular version, or a mobile mail app, will honour it. A developer writing a template needs the second answer, per client, at the time of writing, and a support matrix is the cheapest way to carry that knowledge.

The design choice that shapes everything is that the site is a Jekyll site served as GitHub Pages with a home made theme, using Sass for CSS compilation. There is no database, no admin interface and no content editor. The data is in the repository, in plain files, versioned by Git, and reviewable in a pull request.

That has an obvious upside for accuracy claims and an obvious limit. The tables are as fresh as the last commit, and the documentation says nothing about how test results are gathered, by which client versions, or on what schedule.

Feature data sits in _features, not in a page body

The folder layout explains how the site is put together, and the data folder is the part that matters for anyone wanting to reuse the information.

Data lives in four places. The _data folder holds data files used throughout the site, mainly for settings and labels. The _features folder holds the data for every HTML and CSS feature support, which is the substance of the tables. The _posts folder holds data for the latest news. And a tests folder contains HTML test files to test HTML and CSS features.

The layout side follows the standard Jekyll split. The _includes folder holds files included in other theme files, the _layouts folder holds the main layouts, the _sass folder holds Sass files that are all compiled into one file in the assets/css folder, and assets holds CSS, images and JavaScript files. Beyond that, the repository root carries the usual Jekyll scaffolding such as _config.yml, feed.xml, robots.txt, a CNAME file and a pages folder, plus a _clients directory and a _js directory.

The important structural fact is that a feature support answer is a data record, not a hand written page. That is what makes a table consistent across clients, and it is also what makes the tables easy to regenerate or to diff over time.

Running the site locally with bundle exec jekyll serve

The installation path is the standard Jekyll one, and it is short.

Clone the repository first:

git clone https://github.com/hteumeuleu/caniemail.git

Then install Jekyll and the other dependencies through Bundler:

bundle install

And start the site:

bundle exec jekyll serve

Once that is running you open http://localhost:4000 and you should see the same support tables the live site shows, rendered from the same data files.

There is a faster variant for work on a single feature, because Jekyll can skip regenerating pages that have not changed:

bundle exec jekyll serve --incremental

A second configuration file exists for a different deployment. The embed version of the site, at embed.caniemail.com, is built by specifying the config file to use:

bundle exec jekyll serve --config _config.embed.yml

Since the whole site is a static build with a theme you can read, the practical workflow for a team is to branch, edit a data file, run the incremental build, and open the page in a browser.

The tests folder is the closest thing to a methodology

There is a tests folder in the repository containing HTML test files to test HTML and CSS features. That is the only hint about how the support values are produced, and it is a hint rather than a description.

What it implies is reasonable. Each feature can be exercised by an HTML file that uses it, and the results of running those files against clients are what populate the tables. What is missing is any statement of which client versions are covered, how a partially working result is classified, whether the tests are run manually or by some automation, and how often the results are refreshed. The README does not document a test procedure, and the repository listing shows no dedicated tooling directory for one.

For a reader this matters in a specific way. A support cell is only as meaningful as the method behind it, and a table that says a feature is supported might mean tested on one client build at one moment. Teams shipping to a fixed audience can turn that weakness into a strength, because they can reproduce the check themselves using the HTML test files as a starting point, and the same folder is useful as a test corpus for your own sending pipeline.

Two audiences: the readable table and the embed build

The project serves two distinct use cases, and the embed build is the one that is easy to miss.

The main site is the human facing set of support tables, published at caniemail.com, with the repository also carrying a CNAME file and a feed file for syndication. The embed version, at embed.caniemail.com, is a separate build produced by pointing Jekyll at _config.embed.yml, which suggests a layout designed to be dropped into another page rather than browsed on its own.

That split is a sensible answer to a common request in this space. A table of support data is useful to a human reading a page, and useful in a different way as a small widget or panel on an internal documentation site or an email testing tool. The repository listing shows a _js directory and a _clients directory, which is consistent with a site that renders and filters client data dynamically rather than baking every permutation into static pages.

One more piece of context belongs here, since it bears on trust in a sponsored project. The documentation states that Can I email is sponsored by Resend, a transactional and marketing email sending service. Sponsorship is common in this corner of the industry and does not invalidate the data, but a reader assessing the tables should know the funding arrangement is stated up front rather than discovered later.

Licence, releases and the cost of keeping a local copy

The project is released under the MIT licence, with the licence text linked from the README and a LICENSE file in the repository root. That matters more here than for a typical code dependency, because the practical use of caniemail is copying its data into your own tooling, and MIT terms are the least encumbered way to do that.

The versioned artifacts are the API rather than the site. The release list contains v1.0.4 on 2025-08-01, v1.0.3 on 2020-11-21 and v1.0.1 on 2020-05-20, tagged as API versions. So the data product has its own release line, separate from the commits that build the site.

That gap is the interesting part for anyone automating against it. The site itself is rebuilt on every commit, and the last push was on 2026-09-16, so the tables on the live site move more often than the API releases do. If your tooling depends on a stable snapshot, pin to a release rather than reading the current site. If you want the freshest data, the site is the freshest source, but then you own the change detection.

Running your own copy costs nothing but a Ruby and Bundler toolchain and a place to host GitHub Pages. The main operational cost is review: a fork has to track upstream changes to the feature data, and upstream data changes are exactly the kind of edit that looks trivial in a diff and matters a lot to a template.

Editorial conclusion

Use caniemail as a reference table while writing an email template, especially when a client is named in your audience that you have not tested yourself, and do not treat it as a pass or fail gate, since the repository documents no testing methodology and no refresh schedule for the tables. Before relying on a cell, reproduce it with the HTML test files in the tests folder against that client, and if you need machine readable support data, use the versioned API releases instead of scraping the pages, where the most recent was v1.0.4 on 2025-08-01.

Frequently asked questions

Official sources

1. hteumeuleu/caniemail on GitHub
2. License: MIT
3. Project website
4. README
5. Releases