HTML Email Best Practices: Build Emails That Convert

Your email can look perfect in the editor and still arrive with broken columns, unreadable text, or a missing call to action. That is not just a design problem. It wastes the attention you paid to earn. These HTML email best practices connect the technical work - layout, accessibility, rendering, and deliverability - to the business outcome: getting the right person to take the next useful step. Whether you run lifecycle campaigns in HubSpot, send product updates, or manage an outsourced marketing program, the goal is the same: build a reliable template, test the actual send, and measure what happens after the click.

Before anyone opens a template builder, write down the audience, the trigger, and the desired action. A welcome email should help a new subscriber get started. An abandoned checkout reminder should make returning to checkout easy. A B2B nurture email should answer a buying question or move a qualified prospect toward a conversation. Different jobs need different messages.

Choose one primary conversion goal. That does not mean every email must contain exactly one link. A newsletter can offer several articles, and a receipt needs supporting information. But readers should not have to decide whether your real priority is a demo booking, a webinar registration, a product launch, or your latest social post. Make the primary action visually and verbally obvious.

Match the destination to the promise. If the button says “See implementation pricing,” do not send people to a generic homepage. Check that the landing page works on mobile, preserves campaign tracking, and offers the next step described in the email. Improving a button’s appearance cannot compensate for a disconnected buying journey.

Email clients do not share a consistent rendering environment. Gmail, Apple Mail, Outlook variants, and mobile apps handle HTML and CSS differently. Classic Outlook for Windows is especially important to test when your audience includes corporate buyers because its rendering engine has limitations that differ from modern browser-based clients. New Outlook and Outlook on the web are separate testing targets.

For broad compatibility, presentation tables remain a practical foundation for structural layout. Mark layout tables with role="presentation" so assistive technology does not treat them as data tables. Keep the structure simple, use explicit widths where appropriate, and place critical styles inline. An embedded style block can handle responsive adjustments, but the message should remain usable if those enhancements are ignored.

Do not make essential content depend on JavaScript, complex forms, CSS Grid, or a background image rendering correctly. Support for interactive features varies, and scripts are generally blocked. A normal link to a landing page is usually a more dependable choice for a form submission or complex interaction. Treat advanced email features as optional enhancements, not requirements for completing the primary action.

You do not necessarily need a custom-coded template. A well-maintained email platform template is often the faster option. The deciding question is whether it survives your audience’s email clients, supports your content, and remains easy to update. Custom HTML is useful when the existing builder cannot meet those requirements - not simply because custom sounds more sophisticated.

A single-column layout is a strong default for most marketing emails. It gives you a predictable reading order, reduces mobile layout problems, and makes the primary call to action easier to find. A desktop content width around 600–640 pixels is a common starting point, not a universal rule. Use a fluid outer structure that can shrink to the available screen width.

Start body text around 16 pixels and adjust for the typeface and audience. Give paragraphs enough line spacing to remain readable, and avoid long stretches of centered text. Buttons should be comfortable to tap; a target height around 44 pixels is a useful practical starting point. Leave space between adjacent links so a thumb does not accidentally select the wrong destination.

Use media queries to improve spacing, resize elements, or stack columns where supported. However, the base layout should still work without them. If a two-column design becomes a cramped miniature desktop page when a media query fails, it is too dependent on that query. Build the simplest acceptable fallback first, then add responsive refinements.

An image-only email creates several avoidable problems. Recipients may block remote images, screen readers cannot interpret a promotional graphic as normal text, and tiny embedded lettering becomes difficult to read on mobile. Keep the offer, essential details, and call to action in live HTML text. Let images support the message rather than carry all of it.

Write useful alternative text for informative images and use empty alt attributes for purely decorative ones. A product image might identify the product and the relevant variation. A decorative divider needs no spoken description. Do not turn alt text into a second sales pitch or fill it with search keywords; this is an accessibility feature, not an SEO placement.

Resize and compress images before uploading them. Use appropriate formats with dependable email-client support, commonly JPEG or PNG, and test any less widely supported format. Set display dimensions to reduce layout shifts, use absolute HTTPS image URLs, and avoid placing important text over a background image without a tested fallback. The message should still explain itself before the images load.

Accessibility starts with the reading experience. Use a logical content order, meaningful headings, descriptive links, and sufficient contrast. For normal-sized text, a contrast ratio of at least 4.5:1 is a useful WCAG benchmark. Avoid communicating meaning through color alone: an overdue notice needs words that explain the status, not just a red label.

Make link text specific enough to make sense outside its surrounding sentence. “Review your onboarding checklist” tells the reader more than “Click here.” Keep font sizes readable and do not put a critical qualification in tiny, low-contrast footer text. Where your platform allows it, set the document language in the email template and check the reading order with a screen reader.

Dark mode requires testing because clients can preserve, modify, or invert your colors differently. A transparent dark logo may disappear against a dark background, while a button can lose its intended contrast. Use logos that remain identifiable across backgrounds, define sensible foreground and background colors, and inspect actual results. Dark-mode CSS can help in supporting clients, but it does not offer universal control.

There are two separate weight problems: the size of the HTML and the size of the downloaded assets. Heavy images slow the visual experience. Bloated HTML can trigger clipping or make templates difficult to maintain. Gmail commonly clips messages when the HTML exceeds roughly 102 KB, although the exact result can depend on message processing and context. Leave headroom rather than targeting the boundary.

Template builders can accumulate nested tables, duplicate styles, editor metadata, and unused content blocks. Remove what you do not need, but do not delete client-specific compatibility code without understanding it. A smaller template that breaks in Outlook is not an improvement. Check the final generated HTML after personalization and platform processing, not only the clean source file your developer started with.

Clipping matters because readers may not see the full message, including footer information, without expanding it. Tracking can also be affected depending on where tracking elements appear. Keep the primary action reasonably early, make the whole email concise enough for its job, and verify that unsubscribe information remains easy to find. For background, review Mailchimp’s explanation of Gmail clipping.

Build the primary button with live text and a real hyperlink rather than embedding the entire button in an image. A table-based button is a dependable option; some Outlook-specific designs may require a tested VML fallback. The surrounding message should explain why the action is useful. “Book a 20-minute product walkthrough” is more informative than “Submit,” provided the destination actually offers that experience.

Personalization needs fallback rules. Missing first names, outdated company fields, or an incorrect account owner can make a carefully designed email feel careless. Test records with empty values, unusually long names, non-Latin characters, and different lifecycle stages. Conditional sections must collapse cleanly without leaving blank spaces or removing information the reader needs.

This is where CRM implementation and pipeline data become part of email quality. A template cannot decide whether someone is already a customer unless the underlying fields and segmentation are trustworthy. Define ownership for those fields, document the audience rules, and suppress contacts who should not receive the campaign before polishing another visual detail.

A dependable production process separates reusable components from campaign-specific content. Lock the core header, footer, typography, button styles, and legal elements. Let the campaign owner edit the message, images, audience, and destination within agreed limits. That makes routine sends faster while reducing the chance that a rushed change damages rendering or removes a required footer link.

Anton Chisliuk · AI Marketing Ops uses an operator model: one senior builder connects strategy, CRM, content, and workflows rather than handing each piece to a separate account layer. Cleverence’s growth from zero to 2,000 inbound leads per month is a documented broader marketing result, not an HTML email case study. The relevant lesson is connected execution and clear ownership; the operator approach puts the system and its handoffs in scope, not just the asset.

AI can help draft copy variants, propose alt text, and flag missing links or inconsistent wording. It should not approve its own generated HTML for production. Require a human to review claims, audience logic, privacy considerations, and rendered output. Keep personal customer data out of unapproved tools, and retain an approved template version so a failed edit can be reversed quickly.

Good HTML does not guarantee inbox placement. Mailbox providers also evaluate authentication, sending reputation, recipient feedback, list quality, and sending behavior. Configure SPF and DKIM correctly, and implement DMARC with appropriate alignment and monitoring. Coordinate changes with whoever owns DNS and sending infrastructure rather than treating authentication as a checkbox inside the design editor.

Use permission-based lists for marketing subscriptions, maintain suppression records, and make unsubscribing straightforward. Some mailbox providers impose additional requirements on bulk senders, including one-click unsubscribe for relevant subscription messages. That uses message headers and processing beyond a visible footer link. Check your email platform’s implementation against current Google email sender guidelines and other providers your audience uses.

Provide a useful plain-text alternative through your sending platform and keep it consistent with the HTML version. Do not assume a particular image-to-text ratio will solve delivery problems; there is no universal ratio that guarantees inbox placement. Similarly, switching to plain text does not make an unsolicited or poorly targeted campaign acceptable. Resolve audience, consent, reputation, and sending-policy issues at their source.

Previewing inside your editor is necessary but insufficient. Send through the production platform to a controlled test group and inspect the resulting message. Platforms can rewrite links, inject tracking, expand personalization, and transform HTML. Those changes are part of the email your customer receives, so they need to be included in quality assurance.

Prioritize a test matrix based on your audience. For many B2B teams, that includes classic Outlook for Windows, Outlook on the web, Gmail, and mobile clients. For consumer audiences, Apple Mail and mobile Gmail may deserve additional attention. Client-detection reports are imperfect, so combine available reporting with what you know about your customers. Rendering tools help cover more combinations, but actual device checks still catch practical problems.

Use a repeatable pre-send checklist rather than relying on someone’s memory. Assign one owner to approve the final version and another reviewer when the campaign has significant commercial or compliance risk. Any material edit after approval should trigger a targeted recheck. A button destination changed at the last minute is still a production change.

• Confirm the audience, exclusions, trigger, and send timing.
• Review the sender name, reply-to address, subject, and preview text.
• Test every link, tracking parameter, button, and landing page.
• Check mobile layouts, dark mode, and images-disabled views.
• Validate personalization, conditional sections, and empty-field fallbacks.
• Verify footer details, unsubscribe behavior, and the plain-text version.
• Inspect final HTML weight and look for clipping.

Open rate is a limited diagnostic, not a reliable revenue proxy. Privacy features such as Apple Mail Privacy Protection can load remote content without a conventional human open. Corporate security systems can also follow links automatically, inflating some click reporting. Use platform filtering where available, and interpret engagement data alongside sessions, form submissions, purchases, and CRM activity.

Define success before sending. An onboarding sequence might aim for completion of a setup task. A nurture campaign might aim for qualified meetings. A commerce campaign might aim for purchases and revenue per delivered message. Track complaints, unsubscribes, and bounces as guardrails. A campaign that generates clicks while damaging list health is not necessarily a win.

Test one meaningful hypothesis at a time. Compare a shorter message against a longer explanation, or a specific CTA against a general one. Keep audience differences and test duration in view, and avoid declaring a winner from a handful of conversions. When volume is low, customer feedback and funnel inspection may be more useful than an underpowered A/B test. Document what changed and whether downstream results supported the decision.

DIY is reasonable when you have a stable template, a straightforward audience, and someone who owns testing. A specialist freelancer can be effective for a contained rebuild or accessibility review. An agency can suit businesses that need substantial creative production and coordinated capacity. A fractional CMO may help set priorities, but implementation still needs an accountable builder.

An operator model fits when the recurring problem crosses boundaries: CRM fields break personalization, workflow rules trigger the wrong message, and nobody owns conversion reporting. Ask any provider what they will actually ship. The scope should name templates, component rules, supported clients, testing, integration work, documentation, and post-launch ownership. Comparing a visual redesign with a full lifecycle implementation on price alone is misleading.

Timing and cost depend on the number of templates, rendering requirements, data cleanup, approval process, and integration complexity. Start with one high-value recurring email rather than rebuilding everything simultaneously. If the template already works but triggers and handoffs do not, focus on marketing automation and workflow reliability before buying another design project.

HTML email best practices are about dependable execution: a clear purpose, compatible structure, accessible content, resilient mobile behavior, and a tested path to conversion. None of those elements works in isolation. A beautiful email with broken targeting is still a bad send, and perfect authentication cannot rescue a confusing offer.

The practical standard is simple: maintain one reliable foundation, give every send an accountable owner, and evaluate results beyond the open. Anton Chisliuk applies that same production mindset across marketing operations: the asset, workflow, data, and measurement need to function together.

If you are unsure whether your biggest constraint is email design, CRM data, or lifecycle execution, the next step is a Growth Audit to identify what deserves attention first.

- What is the best width for an HTML email?

A desktop content width around 600–640 pixels is a common starting point. The more important requirement is a fluid layout that remains readable on smaller screens without horizontal scrolling. Test the final email in your priority clients rather than treating a fixed width as a guarantee.

- Should HTML emails use tables or divs?

Presentation tables are still a dependable choice for structural layout when broad client compatibility matters, particularly for classic Outlook for Windows. Divs can work for some content and modern-client layouts, but they should not replace tested structure without checking your audience’s rendering environments.

- Is inline CSS required for HTML email?

Inline CSS is a strong default for essential formatting because support for embedded styles varies. Use embedded CSS for responsive enhancements where supported, while ensuring the core message works without them. Many email platforms inline styles automatically, so inspect what your platform actually sends.

- How can I prevent Gmail from clipping my email?

Keep the final HTML comfortably below Gmail’s commonly observed clipping threshold of roughly 102 KB. Remove unused blocks and unnecessary markup, then check the processed email. Compressing externally hosted images improves loading speed but generally does not reduce the HTML size responsible for clipping.

- Are plain-text emails better than HTML emails?

Neither format is universally better. Plain-looking messages can suit personal outreach and direct updates, while HTML supports structured newsletters, product information, and branded lifecycle messages. Choose the format for the task, offer a useful text alternative, and judge performance using downstream outcomes.

- How often should an HTML email template be tested?

Run basic quality assurance before every campaign and broader rendering tests after structural changes, platform migrations, or major component updates. Recheck important evergreen automations periodically because clients, links, products, and business rules change even when the template itself stays untouched.