How to Export an Email and Load It into Any Sending Platform

A finished HTML email loads into any sending platform by one of four routes: pasting code, a file, an archive or a programming interface. On import the platform adds its own tracking code and an unsubscribe link, so the email must be checked afterwards. Below is the sequence and eight verification points.

Why building and sending are separate jobs

Splitting these jobs is not a technical accident but sensible organisation. Building an email and sending it demand different things: the first is about design and client compatibility, the second about lists, segmentation and deliverability.

The practical benefit shows when the sending platform changes. The list moves, the emails stay: they do not need rebuilding in a new editor. The same applies to an agency whose clients use different platforms.

The exchange format is plain HTML, understood by any platform, because emails everywhere are built the same way: tables, inline styles and separate code for older clients.

Four upload methods

The method depends on what a given platform offers. Usually the first two are available, less often all four.

Pasting code is the most universal route. Practically every platform has a mode for creating an email from finished HTML, labelled roughly the same way: import, paste code, create from HTML.

What happens to the code on import

It matters to understand that the platform does not take your code as is. It makes changes, and some of them can affect appearance.

• every link is rewritten to the platform own addresses so clicks can be counted
• a tracking pixel is added at the end
• a mandatory unsubscribe link is added to the footer
• sometimes a sender address is added where the law requires it
• occasionally styles get rewritten: some platforms do this aggressively

The first two items increase the email weight, and that is worth planning for. If your HTML weighed ninety kilobytes, adding tracking can push it past the clipping threshold.

Hence a practical rule: keep the email under eighty kilobytes when building, so there is headroom for the tracking code.

An unsubscribe link is added automatically nearly everywhere, but its styling rarely matches your brand. It is wiser to add your own visible link to the footer at build time: the automatic one then becomes a duplicate rather than the only one.

Personalisation variables

Personalisation is the one place where an uploaded email needs manual adjustment to a specific platform. Each uses its own variable syntax.

The mechanism is the same everywhere: a special marker goes into the copy, and on sending the platform replaces it with a subscriber data. But the marker is written differently, and one platform marker will remain visible text in another.

• find the variable syntax in your platform documentation before building the email
• insert the markers during the build rather than after uploading
• always set a default value in case the field is empty
• send a test to an address with complete data and to one with empty fields

The last point saves you from the most visible campaign failure — an email showing an unmerged variable instead of a name. Checking takes two minutes and cannot be fixed after sending.

Images: where they should live

Images have two hosting options, and the choice affects speed and reliability.

The first is keeping images on your own storage and putting direct links in the email. Changing sending platform then breaks nothing, and an image can be replaced without rebuilding the email. One requirement: the storage must be permanently available.

The second is uploading images into the platform along with the email, usually as an archive. The platform then hosts them and substitutes its own addresses. More reliable for a one-off send, but it ties the email to that platform.

For most cases the first option is more convenient, particularly when there are many emails and some images repeat.

Checks after uploading

Checking after upload is mandatory: the import makes changes, and their consequences show only in practice.

• send yourself a test and open it on a phone, not only on a desktop
• click every link: the platform rewrote them and a typo could arise on import
• check name substitution on two addresses, with and without data
• look at the email weight after import rather than before
• confirm the unsubscribe link is present and working
• check how it renders in dark mode
• turn off image loading and confirm the meaning survives
• open the email in an older client if your list contains such users

The first item matters most: most people will open on a phone, and a desktop check will not show that.

If something broke

Import failures are few and nearly all have a simple explanation.

• the layout shifted — the platform rewrote styles, try uploading a file rather than pasting code
• images do not show — check that links are absolute rather than relative
• a marker appears instead of a name — the variable syntax does not match this platform
• the email is clipped — weight passed the threshold after tracking code was added
• buttons stopped being clickable — the platform editor re-saved the email and simplified the code

The last case is the most common and has one cure: do not open an imported email in the platform block editor. Many platforms simplify code on save and lose compatibility techniques. Once the HTML is uploaded, send it without editing.

Mailvex exports an email in three formats: clean HTML to paste, a file to upload and an archive with images. The weight is visible in the editor before export, so headroom for tracking code is planned in advance.

Tag profiles insert variable syntax for common platforms automatically, so personalisation works without hand-editing code. A test send to your own address runs from the editor, before export.

Frequently asked questions

Will exported HTML work with any sending platform?

Yes, provided the platform accepts finished code, which practically all do. Only the upload method and the personalisation variable syntax differ, and that is worth confirming in the platform documentation.

Can I edit the email in the platform editor after uploading?

Better not to. Many block editors simplify code on save and lose compatibility techniques for older clients. It is safer to make edits where the email was built and upload again.

Where should images be stored?

On your own storage with direct links when there are many emails and some images repeat: changing sending platform then breaks nothing. Uploading an archive is easier for a one-off send.