Email coding vs web coding: what’s the difference?

Kristina Lauren

August 25, 2021

A breakdown of the differences between web development and email development.

You’ve built a website, but now you need to build an email

Let’s say you have a bit of experience coding with HTML, CSS, and JavaScript and you’re looking to give coding your first email a shot.

Of course, you expect designing an email to be somewhat different from developing for web browsers, but you may be surprised to learn that some of the basic tools and elements you use to code for the web aren’t always available for developing emails.

That’s why in this article, we’re going to take a look at some important differences between coding for the web vs coding for email.

Let’s talk about standards

Web development is quite standardized, but this didn’t just happen on its own. The early days of the web were chaotic—web browsers would create vastly different methods of rendering code, which forced developers to create multiple versions of a website to make sure it would render properly on each browser. Developers became understandably frustrated with this, which led to the World Wide Web Consortium creating guidelines for web coding and rendering in the early 2000s. These standards not only gave developers a consistent set of coding rules, but they also created a more uniform experience for users of the web that everyone enjoys today.

Email, on the other hand, is largely still stuck in the early 2000s. Due to a lack of official guidelines, email clients are pretty much free to render code however they want. This means varying support for many design elements, little consistency among email platforms, and the need for various hacks just to get a single email to render uniformly across web, desktop, and mobile clients.

So, how does this affect styling?

In web development, you have HTML, CSS, and JavaScript at your beck and call. With CSS specifically, you have the option to use inline styling, or to link an external stylesheet to the HTML file. The latter tends to be the best practice, especially when large amounts of styling is necessary because having a file solely dedicated to CSS helps keep your code nice and neat.

In email development, you can only use HTML and CSS. On top of this, some clients will remove internal styling in the <head> section, including any linked external CSS files, leaving your emails stripped bare with awkward formatting and no style.

That’s why the best practice is to keep all CSS styling inline—within the HTML tags themselves to ensure that nothing gets lost regardless of whichever client renders your email.

There are also a few restrictions as far as certain CSS properties go. For example, display: none;, which is also commonly used with JavaScript, is not supported by all email clients, so don’t rely on it to keep any design elements hidden from your viewers.

Despite CSS limitations, you can still style your emails effectively, it just takes a little more effort and creativity.

What about layout?

In web development, you get plenty of flexibility as far as layout goes. With the availability of div elements as well as the introduction of systems like CSS Grid, positioning elements has become much more intricate and even easier than it was in the past.

Though, when it comes to email, tables are your best friends. In absence of div elements, tables can be used to align content in different directions, set padding and margin, or create buttons with clickable text. In fact, tables also provide some stabilization when it comes to ordered and unordered lists. <ol> and <ul> tags don’t work properly with all email clients. Sometimes the spacing between the bullet points can be a little off, or the bullets might go missing all together, but tables help prevent this by holding everything together.

As you begin coding, you’ll notice the necessity for nesting—building tables within tables. However, you should be careful not to over-complicate your layout with too much nesting. It’s easy to make silly mistakes when you’re dealing with a bunch of tables—you might accidentally insert a table somewhere it doesn’t belong or forget to correct another important piece of your HTML if you have to shift around any of the tables. Some clients may also clumsily render your email if your tables are nested too deeply. To avoid this, try to stick with 5 tables at the most.

How can photos and videos be embedded in emails?

Using some kind of graphic in your email may seem like the best way to capture the attention of your subscribers, but you can’t always count on visuals to fully convey your message. By default, many email clients block images and some of your subscribers–either due to preference or a lack of knowledge–may have automatic image loading turned off. To prevent leaving your subscribers completely in the dark in this situation, use alt-text with your graphics. If nothing loads, your viewers will still have a general idea of what the visuals are supposed to be.

So, what about videos? As you probably guessed, those aren’t supported by most clients either, but there’s a neat workaround for this issue. If you’re keen on featuring videos in your emails, you can simply use a photo, place a play button icon on the photo, and embed a link onto the graphic. Then, when email viewers click on the “video” to play it, they’ll be redirected to a web browser where the actual video will play.

Another option that we recommend is for you to use gifs. You can convert your video into a gif and insert it into the email so that viewers can at least see the video visuals without being redirected. The movement of the graphics will not only catch your viewers’ eye but can also aid in holding their attention longer.

Which fonts are supported in emails?

We’ve talked about fonts a couple times on our blog now and emphasized the importance of choosing fonts that are safe for email. Since you may not have control over how various email clients display your text, you’ll want to pick a font that the vast majority of clients will have in stock, such as Arial or Helvetica. While these common fonts might not perfectly reflect your brand like more unique fonts would, you should still be in good hands so long as you use the same email-friendly font consistently throughout your campaigns.

If the idea of an email-safe font isn’t appealing, you also have the option of using a resource like Google Fonts, which will provide you with code for a plethora of font families that you can copy and paste into the <head> section of your HTML file. But remember, some email clients will strip this section of the file, leaving your text at the mercy of whatever fonts your subscribers’ email clients decide on. To be safe, you should always include a fallback font within your inline CSS.

Conclusion

The chasm of differences between web and email development can be shocking to learn about, but this doesn’t mean that you still can’t produce some amazing emails for your audience. There is a great deal of tricks and hacks you can use to get the perfect email design–we actually go over some very helpful ones in one of our articles that focuses on building emails from scratch. However, if you’d prefer to use a template that’s already been built by our team of experts, check out the Scalero app to get started.