HTML code for Email
This article is for users who want to bring custom HTML code into their emails — both experienced email developers and marketers who occasionally need to paste in snippets from a design team.
Email HTML isn't quite like web HTML: email clients are stricter, render differently, and ignore many modern CSS features. This guide covers what works, what doesn't, and the best practices to follow when using the HTML Element in the Apsis One Email editor.
💡 Prefer a visual approach?
The Apsis One Email editor's drag-and-drop Design Elements cover most common email needs without any coding. Use the HTML Element only when you need something the standard Elements can't deliver — like a custom price table, a complex data-driven layout, or a branded module designed by your development team.
In this article
Best practices
Pay close attention when pasting HTML code into the Element — poorly structured code can interfere with the rest of your email and break the layout. The following guidelines will keep your custom HTML working smoothly alongside the drag-and-drop content:
Use simple inline CSS. Email clients strip or ignore much of what works on the web. Inline styles are the most reliable.
Use web-safe fonts. If an email client does not support a font, it will be replaced by a fallback font — which may not match your design.
Respect the template width. The standard range is 600px to 800px. Going wider causes horizontal scrolling, especially on mobile.
Tables are your friend. You may create static, nested, and other HTML tables — they remain the most reliable way to structure email layouts across clients.
Test custom web fonts. Pay special attention to your email's preview when using fonts loaded from an external source.
Use background images, image maps, and oversized layouts with caution. Outlook and older clients handle these poorly.
Test embedded CSS across clients. If you plan to use embedded (not inline) CSS, verify your email in Litmus or a similar rendering tool before sending.
Links in the HTML element cannot be tracked by Google Analytics. If tracking is important, use the standard Button or Text elements instead.
💡 Tip — Work with your dev team
If you're not comfortable writing email HTML from scratch, send a clear brief to your development or design team and paste their tested code into the HTML Element. Email HTML is a specialty of its own, and getting expert input upfront saves a lot of rework.
Restricted elements
The following elements are not supported — or not recommended — when working with the HTML Element in Apsis One. Most are blocked by email clients themselves, so even if they work in the Email editor's preview, they will fail when the email is delivered to recipients.
Element | Why it's restricted | Alternative |
JavaScript | Blocked by most email clients to prevent malicious content hidden in emails. | Use strong design, captivating content, or GIF animations to add visual interest. |
Flash | Refers to animated content created with Adobe Flash. Most email clients block it, and Flash itself has been deprecated. | Use GIFs or static images instead. |
Iframe | Used to embed content from another website. Blocked by most email clients because they can contain scripts. | Link to an image that takes Profiles to the external website. |
Media (<video> / <audio>) | Very few email clients support HTML5 video and audio tags for embedded media. | Use a linked image (for example, a play-button thumbnail that opens the video in a browser). |
Forms | Submitting form data requires JavaScript — and JavaScript is blocked by most email clients. | Use an Apsis Form hosted on a landing page, and link to it from the email. |
Device compatibility
A significant share of emails are opened on mobile devices, so your HTML code needs to work on both desktop and mobile. Always use the Preview and Email Client Test features in the Email editor to verify how your content renders before sending.
The best rule of thumb is to create one version of your content optimised for mobile and another optimised for desktop. You can achieve maximum compatibility by using one of the two methods below.
Method 1: Row visibility in HTML code
Instead of creating two Rows with two HTML Elements, you can use Apsis One's default classes inside a single HTML block to show or hide content on specific devices. This is the more compact approach — especially useful when your HTML code is self-contained.
The following CSS rule is how the Email editor hides Rows across devices. Any element inside a .hide wrapper will be hidden on the selected device:
.hide, .hide th, .hide table, .hide tr, .hide td, .hide div, .hide a, .hide img, .hide span
{ display: none !important;
line-height: 1px !important;
max-height: 0px !important;
max-width: 0px !important;
opacity: 0 !important;
overflow: hidden !important;
mso-hide: all !important;
}
See the Stylesheet classes section below for the complete list of mobile classes you can use inside your HTML.
Method 2: Row visibility in Row Settings
A simple alternative is to work with HTML code the same way you'd work with standard Design Panel elements — creating two separate Rows with two HTML Elements, and using the Row Settings to show each one on the right device only.
Here's how:
Add a HTML Element into the Canvas and paste the HTML code for either the desktop or the mobile version of your email.
Click the Row in the Structure panel to open the Row Settings.
Give the Row a descriptive name — for example, "Header – Desktop HTML" — so you can identify which Row contains which version in the Structure panel.
Click the mobile or desktop icon to choose which device the Row should be visible on.
Repeat for the second Row, containing the alternative version of your HTML code.
⚠️ Don't forget the alternative
If you hide a Row on one device, make sure you have an alternative Row for the other — otherwise, part of your audience will see an empty space where your content should be.
If you intend to use an HTML element that isn't covered by Apsis's default classes, test your email with Litmus or a similar tool to confirm it's hidden as intended.
Images in HTML code
Images in HTML email require a bit more care than images on a web page, because your recipients' email clients and connection speeds vary widely. Follow these guidelines for the best results:
Host images on your own server. This ensures the images are available at the time of sending and remain online for as long as you need them.
Keep replacement images the same dimensions. If you later replace an image used in the HTML Element, a different size can break the surrounding layout.
Add image width as an inlined style. This is especially important for Outlook, which otherwise may render images at their native dimensions.
Keep file sizes small. The average image on the web is 2–2.5 MB, but for email we recommend 1 MB or less. Recipients must load all email content to view it, and those on slower connections or restricted data plans are easily affected.
These same guidelines apply to the standard Image element in the Email editor, since you can add an image via a URL there as well.
Stylesheet classes
The Email editor has a default stylesheet that controls how the Canvas renders all Elements from the Design Panel. When writing HTML code for your emails, it helps to know which classes are available so that your code behaves consistently with the rest of the email.
General classes
Class | What it does |
| Removes padding added to images by certain email clients. |
| Shows the element at 100% width. |
Mobile classes
Class | What it does |
| Shows a Row in mobile — add to the surrounding table. |
| Hides the element in mobile. |
| Displays the element as |
| Displays the element as |
| Displays the element as |
| Displays the element as |
| Removes all padding from the element. |
| Adds 10px bottom padding. |
| Shows the element at 100% width on mobile. |
| Shows the element at half width on mobile. |
| Aligns the element's content to center on mobile. |
💡 Tip — Combine classes
You can combine multiple classes on a single element — for example, class="FullW m-align-center" to display full width on desktop and centre-align on mobile.
Troubleshooting
Issue | What to check |
The HTML layout looks different in Outlook than in the preview. | Outlook uses the Microsoft Word rendering engine and handles CSS differently. Use inline styles, add explicit image widths, and avoid |
A font looks wrong when the email is received. | The recipient's email client doesn't support your custom font and has substituted a fallback. Use web-safe fonts, or define a reliable fallback in your font stack. |
Clicks on HTML links don't appear in reports. | Links inside the HTML Element are not tracked by Google Analytics. If click tracking matters, use the standard Button or Text element for that link. |
Images appear stretched or tiny in Outlook. | Add both |
Mobile version shows content meant for desktop. | Confirm Row visibility is set correctly in Row Settings, or verify your |
A form, video, or iframe doesn't display. | These elements are blocked by most email clients. See the Restricted elements section for alternatives. |
What's next?
HTML Element — How to add and work with the HTML Element in the Email editor.
Design Elements — The complete list of drag-and-drop Elements available in the Email editor.
Best Practice – The Successful Email — Tips for creating effective email campaigns.
FAQ: Email design looks different in Outlook? — More on rendering differences between email clients.