Email Boilerplate 1.0

My framework for making HTML emails

Expanded Email Hyperlink 1.0


Ask anyone in front end development about coding an HTML email, and you’ll encounter a myriad of groans with a few clever smiles, but a lot of stories of the challenges of email development. It’s not the same as coding for a website, as we’re often using older forms and logic in HTML while now trying to slide in some modern techniques that some devices will allow.

I’ve coded emails for years, as it’s still an in-demand skill due to the popularity and low-overhead of sending mass emails. With many potential employers and clients asking for techs who can code emails, I wanted to share my boilerplate that I use as a starting point for email development.

A look at the modules of my email boilerplate and an example of a mobile email.


Before the age of responsive design, I had been simply using the stable formula of coding in HTML 4.01, using tables and font tags first, but also using styles when I could, but inline. A lot of that methodology is still relevant today, but the age of smartphones has given us more flexibility in what we can do within the email space.

This boilerplate is broken down into modules based on scenarios I normally encounter. Some modules might become questionable on feasibility or best practices, like hiding navigation, using a background image or even having a full image marquee; but this really comes down to your client and your end users in how they are looking at email. It’s important to get up-to-date statistics and always test your layouts. If you can’t afford a full testing platform, then try free solutions like PutsMail and do the leg work on whatever devices and email clients you can set up.

Results and Takeaways

This boilerplate has worked well for me, although the look and feel of the end result changes based on the client in question. If you’re planning on using such a boilerplate for repeated usage on a particular client, I highly recommend versioning the file to create a colored and branded boilerplate for that particular client. Remove modules you know you’ll never use, and style the rest to fit what the brand guidelines entail. It’ll speed up your development process.

I will be updating and adding to this boilerplate as new breakthroughs come in email development, as well as adding in any new modules I see a need for. It’ll all be here and on my Github.