How to Send HTML Emails with Embedded Images in Make.com

Choose the image method before building the scenario

Make.com can pass HTML to an email module, but it does not make every HTML and image technique equally reliable. The right implementation depends on whether the image is decorative, essential to understanding the message, generated dynamically, or likely to change after the email is sent.

For most logos, banners, and decorative graphics, a stable public image URL is the sensible default. Consider a data URI only when there is a clear reason the image must travel with the email and the receiving clients have been tested.

Build the email around a real business state

Before writing HTML, identify what event causes Make.com to send the message and what the recipient must do next. Examples include a payment requiring review, a new lead needing ownership, an order moving to fulfilment, or a scheduled report becoming available.

This prevents a common automation mistake: designing a visually polished email before deciding what information is authoritative. The email should represent a known state from the source system. Its image should support that state, not compensate for unclear data or missing ownership.

For example, suppose a Make.com scenario sends a weekly operations report with a chart image. The workflow should define which reporting period the image represents, where the numbers come from, and who is responsible for acting on exceptions. The image is then one part of a controlled reporting process rather than an isolated visual element.

Use hosted images in Make.com when simplicity matters

A hosted image uses a standard HTML image element. In a Make.com email module that accepts HTML, the essential pattern is an image source, meaningful alternative text, and an explicit width. Keep the surrounding layout simple and avoid depending on background images or advanced CSS.

The image URL must be accessible to the recipient’s email client. A URL that works only while logged into a company application will usually fail when the inbox attempts to retrieve it. Review whether the hosting service requires authentication, blocks automated requests, expires links, or changes the file path.

• Use HTTPS and a stable URL.
• Provide descriptive alt text that explains the image’s purpose.
• Set a practical width so the layout does not expand unexpectedly.
• Use display:block to reduce gaps that can appear below images.
• Keep important meaning in text as well as in the image.

Hosted images are also easier to update operationally. A company logo, status badge, or campaign banner can be replaced at the source without changing the Make.com scenario. That flexibility is useful, but it also means the message may look different when opened later. Use versioned or immutable asset URLs when historical consistency matters.

Use data URIs only when the trade-off is justified

A data URI combines an image MIME type, the base64 marker, and the encoded file content. In conceptual form, it looks like data:image/png;base64,encoded-image-data. The complete value is inserted into the HTML image source.

In Make.com, the workflow normally needs to obtain a binary image, convert it to base64, add the correct MIME type, and construct the HTML after the conversion is complete. The exact mapping depends on the module that supplies the file and the tools used in the scenario, so validate the output rather than assuming that a file object can be placed directly into the HTML.

Data URIs are not a universal solution. Base64 encoding increases the size of the image data, and large messages can create slower processing, larger storage requirements, or delivery issues. Some clients may remove or refuse the image even though it is embedded in the message.

A useful decision rule is simple: use a hosted URL unless the image must be self-contained and the size and compatibility consequences are acceptable.

Design a resilient HTML email template

Email HTML is not the same as browser HTML. Email clients apply different rendering rules, remove some markup, and may disable remote images until the recipient allows them. A robust template therefore favours predictable structure over visual complexity.

Use a narrow central container, table-based layout where broad client compatibility is important, inline styles, and clear text. Put styles directly on the elements that need them instead of relying on a stylesheet in the head. Give images explicit dimensions and avoid using an image as the only source of a call to action or important instruction.

A practical structure is a full-width outer table, a fixed or maximum-width content table, a header image, a text section, and a plain text explanation of the next step. In Make.com, keep the template readable by separating static HTML from mapped values. Dynamic fields should be inserted only where the source data is expected and validated.

Do not allow untrusted values to become arbitrary HTML. If a customer name, product title, or status label is mapped into the template, account for special characters and keep user-provided content in text positions. This reduces broken markup and limits the risk of unsafe content being rendered.

Use a practical Make.com implementation sequence

A dependable scenario separates file preparation, content decisions, rendering, and delivery. That makes failures easier to diagnose than a single step that tries to fetch an image, assemble HTML, and send an email at once.

If the scenario supports it, route invalid image inputs to an error path rather than sending a broken message. The fallback might use text only, a replacement image, or a link to a controlled page. The correct choice depends on the business purpose of the email.

Test the rendered result, not just the scenario run

A successful Make.com execution confirms that the scenario completed. It does not confirm that the recipient sees the intended email. Testing should include the message source, the HTML output, and the rendered result in representative inboxes.

Send test messages to the email clients used by the audience. Check whether the image loads, whether the layout remains usable on a narrow screen, whether alt text appears when images are blocked, and whether long dynamic values distort the design. Also test a missing image and a malformed or inaccessible URL.

For generated images, compare the image content with the triggering business record. A technically valid image can still be wrong if it was generated for a previous reporting period, another customer, or a different status. This is why data validation belongs before HTML assembly.

When an email is operationally important, log enough information to explain what happened: the source record, template version, image method, send time, and error result. Avoid logging sensitive image data unnecessarily. The goal is traceability, not a second copy of every message asset.

Keep ownership and maintenance visible

HTML email automation often fails over time because no one owns the asset, template, or scenario. Define who maintains the hosted image, who approves template changes, who investigates failed sends, and who decides when an email should be retired.

Keep image files in a location with stable permissions and a clear naming convention. Document whether a URL is expected to remain permanent or whether it is generated for one message only. If the email depends on a CRM, reporting system, or file storage service, document the handoff between those systems.

For broader workflow work, Make.com automation services can help connect scenario logic with data validation, ownership, and error handling. Where the email is part of a wider operating process, the systems and automation services page provides a broader view of implementation support.

Examples of connected operational work are also available in the ConsultEvo client work portfolio. The relevant lesson is not that every process needs more automation. It is that automation is more useful when the underlying handoffs and data states are clear.

Diagnose common image problems

The image does not appear

Check whether the URL is public, uses HTTPS, returns an image rather than an error page, and remains valid outside your authenticated browser session. If it is a data URI, inspect the MIME type, base64 value, and final HTML output.

The email layout breaks

Look for missing dimensions, unsupported CSS, oversized content, unescaped dynamic values, or a template that depends on browser-only behaviour. Simplify the layout and move important information into normal text.

The image appears in testing but not for recipients

The recipient’s client may block remote images, restrict data URIs, or use a security proxy. Confirm that the message remains understandable without the image and that the URL is not dependent on a session or short-lived token.

The scenario sends the wrong image

Trace the image back to its source record and confirm that the mapping uses the current bundle. Add a validation step that compares the image identifier or reporting period with the record that triggered the email.