How to paste custom HTML into Mailchimp
In Mailchimp, create a campaign, choose the "Code your own" template, then pick "Paste in code" and drop your full HTML into the editor. Save and the design becomes your email. Use inline CSS, include Mailchimp's required merge tags for the unsubscribe link and mailing address, and send a test before you launch.
Where the paste-HTML option lives in Mailchimp
Mailchimp does let you use your own code, but the option is not on the front screen. Start a regular email campaign, and when you reach the content step, look for the template picker. Choose the "Code your own" category. Inside it you get two real choices: "Paste in code," where you drop a full HTML document into a text box, and "Import zip," where you upload a .zip that contains your HTML file plus an images folder.
Paste-in-code is the fastest path when your images are already hosted somewhere public, for example on your own CDN or in Mailchimp's content studio. Import zip is the one to use when you want Mailchimp to host the images for you. When you upload the zip, Mailchimp swaps your local image paths for its own hosted URLs.
One thing trips people up here. After you paste code and save, Mailchimp shows the email in a code view, not the familiar drag-and-drop block editor. That is expected. A pasted email is a code email, and you edit it as code from then on. If you later switch it back to a drag-and-drop template, Mailchimp will try to parse your HTML into blocks and usually mangles it, so decide upfront which kind of email you are building.
What Mailchimp changes in your HTML, and why
Mailchimp does not throw your markup away, but it does process it on the way out. It rewrites your links so it can track opens and clicks, appends tracking parameters, and injects its own footer block if your code does not already contain the legally required elements. It also runs your CSS through a step that pushes some style rules inline at send time.
That last part is the reason seasoned email developers inline their CSS by hand instead of trusting a tool to do it. Several email clients, Outlook on Windows and parts of Gmail among them, ignore or strip a `<style>` block in the document head. A background color or font size that lives only in `<head>` can simply vanish in those inboxes. Styles written directly on the element, like `<td style="font-size:16px; color:#222222;">`, survive. So write your colors, spacing, and font sizing as inline attributes on the table cells, and keep the `<style>` block for the few things that can only live there, such as media queries and `:hover` states, which clients that ignore `<head>` styles were never going to render anyway.
Layout is the other place to be careful. Build with nested HTML tables and fixed widths, usually a 600 to 640 pixel outer table, rather than `<div>` and flexbox. Mailchimp will happily send a div-and-flex layout, but Outlook's rendering engine will break it. Tables are not old-fashioned here. They are what holds an email together across thirty years of inbox clients that never agreed on a standard.
Adding the merge tags Mailchimp requires
Mailchimp uses merge tags written in `*|TAG|*` syntax to drop in personalization and compliance content at send time. Two of them are not optional. Every campaign must contain an unsubscribe link and your physical mailing address, or Mailchimp blocks the send.
For the unsubscribe link, put a real anchor in your footer that uses the unsubscribe tag, for example `<a href="*|UNSUB|*">Unsubscribe</a>`. For the mailing address, drop `*|LIST:ADDRESS|*` into the footer text. If you would rather not hand-place these, leave them out and Mailchimp will append its own standard footer automatically, though you lose control of how it looks. Most agencies place them by hand so the footer matches the brand.
Personalization uses the same pattern. `*|FNAME|*` pulls the subscriber's first name, `*|LNAME|*` the last, and any custom audience field becomes a tag based on its merge field name. Always pair a name tag with a fallback so a contact with no first name on file does not get "Hi ,". Mailchimp's syntax for that is `*|FNAME|Hey there|*`, which prints the first name when it exists and the fallback text when it does not. Test these against a real contact, because a typo in a merge tag prints the raw `*|...|*` text straight into the inbox.
Testing the email before you send
A pasted email can look perfect in Mailchimp's preview and still fall apart in a real inbox, because the preview is a browser rendering, not Outlook or Gmail. Build a short test routine and run it every time.
Start with a plain test send to yourself and to two or three coworkers on different setups, ideally one on Gmail in a browser, one on the iPhone Mail app, and one on Outlook for Windows if you can reach it. Open each on the device it was sent to, not forwarded, since forwarding rewrites the HTML. Check that images load, that the layout holds at 600 pixels and then narrows cleanly on the phone, and that your colors and fonts survived. Then turn images off in one client and confirm the email still reads, because a meaningful share of recipients block images by default and a design that is one big image becomes a blank rectangle for them.
Mailchimp also offers Inbox Preview, which renders your email across many client and device combinations from a single screen. It runs on a credit system, so use it for the clients you cannot test live, especially the Outlook desktop versions. Last, send one more live test after any change to merge tags and click every link in it. The cost of a broken unsubscribe link or a raw `*|FNAME|*` going to your whole list is much higher than the two minutes a final test takes.
If you would rather skip the hand-inlining and the table debugging, this is the part Mailwright is built to remove. It produces table-based, fully inline HTML that is already structured to hold up in Gmail, Apple Mail, and Outlook and in dark mode, so the code you paste into Mailchimp is ESP-safe before it ever reaches the editor. You still test, but you start from markup that was made to survive the inbox.
Questions
Does Mailchimp strip out custom HTML or CSS when I paste it in? +
Mailchimp does not delete your markup, but it processes it. It rewrites links for click tracking, can inline some `<head>` styles at send time, and appends a compliance footer if you have not added the required tags. The practical risk is not Mailchimp stripping code, it is inbox clients like Outlook ignoring `<head>` CSS. Inline your styles on the elements themselves to avoid surprises.
Why does my pasted email look broken in Outlook but fine in Mailchimp's preview? +
Mailchimp's preview renders in a browser, while Outlook on Windows uses Microsoft Word's rendering engine. Word ignores `<head>` styles, drops many modern CSS rules, and breaks div-and-flexbox layouts. Rebuild the layout with nested HTML tables and fixed widths, move styling inline, and use bulletproof button markup. Then confirm it with a real Outlook test or Mailchimp's Inbox Preview.
How do I add a first name and an unsubscribe link to pasted HTML? +
Use Mailchimp merge tags in `*|TAG|*` syntax. For personalization, `*|FNAME|*` inserts the first name, and `*|FNAME|there|*` prints "there" when no name is on file. For compliance, add an anchor pointing to `*|UNSUB|*` and drop `*|LIST:ADDRESS|*` into your footer. Mailchimp blocks the send if the unsubscribe link and mailing address are missing.
Should I use paste-in-code or import a zip file? +
Use paste-in-code when your images are already hosted on a public URL or in Mailchimp's content studio, since you are only handing over the HTML. Use import zip when you want Mailchimp to host the images for you. On a zip import, Mailchimp uploads the images in the folder and rewrites your local image paths to its own hosted URLs automatically.
Stop fighting email HTML
Mailwright builds ESP-safe email on your client's brand. Chat a brief, get HTML that renders in every inbox.
Get a free sample