Depending on what email provider you use, chances are good that the code you send to them, or paste into their editor, doesn’t remain completely intact.

Code snippets

Email providers that have their own email builder tool have a certain approach to how they output email code. So any custom code snippets that you add within the editor will likely go through some kind of alteration as the code has to follow the same rules as the email editor for how it outputs its own code.

Check out this community-managed GitHub repo that tracks certain email provider issues to get an idea of some of the changes that are made to code.

Full HTML code

The best way to avoid these changes is to completely custom code your email’s design. This also allows for the most flexibility for your design, and minimizes the potential for code bloat that often comes from email providers.

However, even in this case, there may be some code changes from your email provider. For example:

• In the header, a link to the browser version of your email may get added
• In the footer, an unsubscribe link is added
• Tracking pixels could be placed within your code as well

In most cases, your code isn’t modified the same way as when you add in code snippets in the editor because a separate process is typically used for the above additions. But you may still want to test the final output in either case. You can do this by sending yourself a test email and using a tool like emailpreview.io to analyze the test email's code.

You can also try to avoid these changes as well by using tokens or variables that you can put in your code for things like a link to the browser version and unsubscribe links. For tracking pixels, see if there is a setting to not include them. It’s better for your reader’s privacy and many email apps are now blocking them.

Blocks Edit makes it a priority to keep your code intact as emails are built from it in the visual editor. You can then use that code in your email provider.