HTML and CSS in Emails: What Works in 2022?


Arguably, one of the most exciting aspects of web development in recent years has been a significantly more consistent level of support for new HTML, CSS, and ECMAScript (JavaScript) standards amongst web browsers. However, the same cannot be said for email clients despite the introduction of fresh features such as media queries, flex, rem units, and more. Let’s take a look at some of these features and how we can make them work for all email clients, in 2022.

Table of Contents

Internal CSS

Undoubtedly, one of the most annoying aspects of creating emails is having to declare styles for every individual element within its style attribute (for example <element style=”style:value;”></element>), otherwise known as ‘inline CSS’.

Luckily, internal CSS (i.e. styles written within a <style> element) has more support now. Internal CSS is way more efficient since it enables us to combine selectors and write less code that’s more readable.

According to Can I Email, internal CSS works in 84.85% of today’s email clients, but there are a few rules that must be followed in order to make this happen.

Luckily, all of the rules can be complied with by using two <head> elements/inserting the <style> element into the second one.

However, while the days of styling using ancient XHTML attributes (e.g. <element align=”center”>) are over, support for internal CSS isn’t as high as we’d like it to be, so many email developers still choose inline CSS depending on the target audience.

It’s worth noting that some features (e.g. media queries and custom fonts) can’t be ‘inlined’, so a common approach to coding emails is to use internal CSS for progressive enhancements only and inline CSS for everything else (unless you’d be willing to forfeit custom fonts and cool layouts, of course).

It’s not an ideal approach, but it is what it is.

Note: external CSS (i.e. the <link rel=”stylesheet”> method) only works in 21.21% of today’s email clients, which is a huge shame because it somewhat rules out creating email design systems.

Media Queries

Internal CSS allows us to use media queries, a necessary component of responsive design. Without media queries, emails can end up looking dreadfully linear, and while there’s absolutely nothing wrong with that from a minimalist viewpoint, a vertical design won’t be the right choice in every scenario.

Media queries only work in 75.75% of modern email clients so we recommend designing responsive layouts that degrade into vertical layouts very gracefully.

Additionally, there are some rules to remember…

  • Avoid nested media queries
  • Limit conditions to screen, min-width, and max-width or omit them entirely (@media { … })
Email Media Queries

As mentioned before, media queries can’t be used inline. They must be used within a <style> element, so you’ll very likely be using at least some internal CSS even when inline CSS is your default approach.

Flexbox or Grid Layout

Unsupported CSS isn’t the only bane of creating emails. Traditionally, HTML <table> has been the backbone of email, but must we still do it this way in 2022? Can we not use the modern <div> element with Flex or Grid?

<div> is supported in 100% of today’s email clients, so no issues there. Grid, however, isn’t well supported at all, although display:flex surprisingly works in 84.85% of email clients (it actually has better support than media queries!).

However, flex’s related CSS properties (flex-wrap:, align-items:, flex-direction:, justify-content:, etc.) have terrible support — tables are the better choice.

Naturally, this rules out the possibility of using semantic HTML elements (e.g. <article>) too, which is a shame for readability and accessibility reasons.

Combined with a lack of full support for internal CSS, this means that in practice email development hasn’t really advanced at all and tools are very much needed if we want to avoid the excruciating task of manually coding emails using extremely old HTML/CSS.

Flexbox or Grid Layout

While tables are hard to write (and read), don’t worry, Postcards absolutely loves tables and codes them for you.

Custom Fonts

Although custom fonts are somewhat cosmetic, beautiful typography is the best way to make emails more intriguing, but the easiest method of embedding custom fonts (<link rel=”stylesheet”>) only has 21.21% support in today’s email clients.

Naturally, this only leaves the @font-face approach, which sadly isn’t well supported either (36.36%). However, both approaches afford us the opportunity to suffix font declarations with fallback fonts, so there’s no harm in using @font-face regardless. It’s a relatively simple approach and font embedding services such as Google Fonts* and Adobe Fonts will still work.

12345678@font-face { font-family: Roboto; src: url(“}selector { /* Google font, fallback, fallback */ font-family: Roboto, Arial, sans-serif;}
Custom Fonts

*Oddly, Gmail has the worst support for custom fonts, which includes their very own Google Fonts!