HTML and CSS in Emails: What Works in 2026?
Designing emails with HTML and CSS allows for professional, branded, and visually appealing content. However, crafting emails for different email clients requires knowledge of the limitations and best practices for HTML and CSS in email design. Hereâs a guide to help you create emails that look great and perform well.
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.
Create Email Templates with Postcards Email Builder
Postcards: Email Template Builder
Understanding the constraints of email clients and their varied degrees of CSS support is crucial if you want to style your emails with CSS. This is a quick guide to email assistance for CSS:
With Postcards Email Builder, you can create and edit email templates online without any coding skills! It includes more than 100 components and the AI Suite, which builds and translates full templates from a single prompt.
Free Email BuilderFree Email Templates- Utilize inline styles: Email clients need inline styles, not web sites, which frequently make use of external stylesheets. The âstyleâ tag must be used to directly incorporate your CSS rules in your HTML code as a result.
- Ensure simplicity: Itâs recommended to adhere to fundamental CSS properties like font size, color, and background color because not all of them are supported by email clients. Useless complicated characteristics like shadows, gradients, and animations should be avoided.
- Utilize tables for layout: Email design still makes extensive use of tables, despite the fact that modern online design mainly relies on CSS for layout. To organize your email layout, use tables rather than floats, flexbox, or grid.
- Test your emails to make sure they display properly on all platforms given the variety of email clients and devices available. Proper email testing helps ensure CSS compatibility across clients, and tools like Litmus and Email on Acid can simplify the process.
- Employ fallbacks: Itâs always a good idea to have a fallback in place in the event that an email client doesnât support a specific CSS attribute. For instance, you can offer a fallback font that is more commonly supported if a client doesnât support web fonts.
These recommendations will help you generate appealing and efficient emails that work with the majority of email clients. To ensure optimal compatibility, donât forget to test your emails frequently and modify your CSS as necessary.
Letâs take a look at some of these features and how we can make them work for all email clients, in 2024.
Internal CSS
Undoubtedly, one of the most annoying aspects of creating HTML email templates 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. See the example belowâĶ
&lt;head&gt;
âĶ
&lt;style&gt;
âĶ
&lt;/style&gt;
&lt;/head&gt;
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).
With Pulsetic youâll be instantly notified the moment your website, API, or server becomes unavailable. Monitor uptime from multiple global locations and respond to incidents before your users are affected.
Create beautiful status pages in minutes to keep customers informed during outages and build trust with transparent communication.
Start Monitoring for FreeItâ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 { âĶ })
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.
Postcards helps designers create emails and then automagically outputs code that makes them work in all modern email clients. Internal CSS? Inline CSS? Both? Postcards takes care of everything while you focus on design.
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 2024? 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.
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.
@font-face {
font-family: Roboto;
src: url(âhttps://fonts.gstatic.com/s/roboto/v...
}
selector {
/* Google font, fallback, fallback */
font-family: Roboto, Arial, sans-serif;
}
*Oddly, Gmail has the worst support for custom fonts, which includes their very own Google Fonts!
If you donât want to use a font embedding service or host the font files yourself, you can Base64-encode the fonts, making it easy to embed them into the email itself.
Hereâs what that @font-face might look like (simplified):
@font-face {
font-family: Roboto;
src: url(data:font/ttf;base64,AAEAAAATAQAABAAwR1BPU+Df...
}
All-in-all, custom fonts arenât well supported, however it doesnât take a lot of work to implement them for the email clients that do support them. In the world of email development, this is a rare win.
Postcards can embed any of the 1,358+ Google Fonts, with multiple fallbacks that closely resemble your ideal typeface.
SVG Images
SVGs typically have lower file sizes than their bitmap equals, and when served inline, they donât delay the loading of the email. Unfortunately, SVG has terrible support. Itâs fallback approach (i.e. <picture> with PNG/JPG fallback) is even worse.
Generally speaking, I would avoid SVG for now and stick with PNG/JPG images. If youâre using Postcards itâll compress them anyway so you donât have to worry too much about emails loading slowly. In any case, itâs best to avoid excessive imagery anyway, not only because of slow devices but also so that users donât have to scroll too often when using handheld devices.
As a final note on image formats, itâs worth mentioning that WebP images are unusually supported in 97.05% of modern email clients. Theyâre safe to use.
What about [x] feature?
Weâve now covered the most in-demand features in email development, but that certainly doesnât cover all of the limitations that modern email clients still impose today. For example, text-decoration:, a CSS âfeatureâ that youâd expect to work everywhere, in fact doesnât work in iOS and Android versions of Gmail when using a non-Gmail email address. For email clients that do support text-decoration:, youâll need to explicitly declare it â itâs not automatic.
We must consider every HTML/CSS feature carefully because even some of the most basic ones donât work when certain (sometimes odd!) rules arenât followed:
- CSS border: (100% support, but the border width canât exceed 8px in Windows Outlook)
- CSS !important (91% support, but they must begin with a space and be in lowercase)
- CSS border-radius: (91% support, but the shorthand slash /doesnât work in some cases)
- CSS background: (100% support with a quite a few rules, although nothing too concerning)
Here are some HTML/CSS features that youâll want avoid though, at least until thereâs more support:
- CSS box-shadow: (58% support)
- CSS aspect-ratio: (33% support)
- CSS :calc() (7% support)
- CSS rem units: (53% support)
- CSS Variables: (06% support)
- Semantic HTML (low support and unsupported tags are usually stripped rather than converted to <div>)
Parting words of wisdom
As you can see, email development is still very complicated even though modern features are being introduced. Can I Email is an incredible resource for researching specific HTML or CSS email features, but it can be time-consuming.
Alternatively, you can skip the migraine and use Postcardsâ drag and drop builder to create the email design you want without worrying about which HTML/CSS features work. Postcards knows so you donât have to.
When creating emails with HTML and CSS, prioritize compatibility over creativity. Test rigorously to ensure that your design looks great across all major email clients and devices!
