Comparing the Classic vs. New Marketo Email Editor
Introduction
It’s hard to believe it’s been nearly 10 years since Marketo released “Email Editor 2.0” to great fanfare (which I remember all too well! It was a simpler time, back then).
The new Marketo ‘Email Designer’ experience is certainly a big departure from the ‘classic’ 2.0 Email Editor experience, and for technical folks, the New Editor raises a lot of questions.
How does the New Editor compare to the features currently coded into your Marketo HTML email templates? If everyone is forced to migrate to the New Editor, will it have all the features you need? What happens to all your templates, snippets and modules? What does the migration process look like?
If you have basic design needs, a small marketing team and minimal brand governance requirements, the New Editor may be a perfect fit.
However, larger and more complex enterprise teams must consider design, branding, rebranding, content updates, governance, user roles, and much more, at scale.
It’s with those teams in mind that we are undertaking a deep dive to help you decide if the New Editor can handle what’s in your existing Marketo template configuration, and if you are confident enough in the roadmap to consider migrating in 2026. We’ve incorporated all the latest product releases up to January 2026 in our latest updates.
General FAQs
Do you HAVE to migrate to the New Editor?
All signs point to yes, you will definitely have to migrate to the New Editor at some stage.
Adobe has said the Classic Editor will continue to be available, but they encourage users to start migrating now. They have also stated that they “want to ensure all of you can do everything and more with the new designer” before they retire the Classic editor — but no feature threshold or timeframe has been specified.
What’s clear is that they certainly are planning to retire the Classic editor eventually, which begs the question: will the New Editor reach feature parity with advanced custom-coded templates by the time the Classic editor is retired?
Can I continue to use Classic Editor templates after migrating?
The Classic Editor remains in your instance and can be accessed in the same way as before: there will be no disruption to existing workflows, and nothing changes unless you choose to use the New Editor to create templates, fragments, and emails. You can use a mixture of both as you try out the new editor.
Where is it in my instance?
The new Marketo Editor is a separate tool that is added to your Marketo instance once you have been migrated onto the Adobe Identity Management System. Once you have done this, you will see new options in the Design Studio: Email Templates [New], Emails [New], and Fragments [New]. Creating new assets in these areas will launch the New Editor.
In Marketing Activities, there is a choice between New and Classic editors when creating a new email, and when opening existing emails, Marketo automatically detects whether it should open in the Classic email editor or the new Email Designer interface.
Is it available for landing pages?
No. So far it has only been released for Emails.
Is the Draft and Approved flow the same?
There is still a similar process, although the states are called “Draft” and “Published” in the New Editor, and there are fewer actions that trigger a Draft, which we’ll detail more below.
Where can I keep up to date on future releases?
Keep an eye on this page showing the comparison of old vs. new features and when they are available.
How the new template system works
The New Editor comes with a totally new structure for how the parts of your template system work together.
The New Editor is a drag and drop tool, and you use the same builder interface to create templates, fragments and individual emails.
Instead of templates, modules and snippets, it’s now a system of templates and fragments. In Q4 of 2025, Adobe also added a Brand Themes feature to the mix. Brand Themes contain cosmetic styling such as colors, fonts and font sizes, and can be applied to Templates, Fragments and directly to individual Emails.
Below we’ll compare the classic Email Editor system to the new Email Designer system.
Classic model: templates, modules and snippets
In the classic Marketo model, templates must be built by a developer using the Marketo “Email 2.0” Template Syntax.
Since each template is independent, they can be context-specific and contain custom branding for specific brands or purposes.
Modules belong to a specific template, while snippets are global and can be applied to any template or email – either by adding them to a defined snippet zone, or by placing them into any Rich Text area (which can create challenges for maintaining brand consistency). Snippets can also be shared across Workspaces.
The architecture can be visualized like this:
New model: templates and fragments
The New Marketo Editor’s template architecture is very different.
Modules and snippets have been combined and replaced with fragments, which can be used absolutely anywhere – they can be dropped onto any column of any email or template.
Brand Themes are global libraries of styles (fonts, colors, buttons) applied to emails or templates. Themes and emails select one Brand Theme, which can include up to 6 color variants. Fragments must be manually marked compatible with specific Brand Themes (maximum five per fragment).
If using multiple Brand Themes, the same theme must be selected for both the template/email and the fragments. This creates a dependency: you should only drag a fragment into an email if it has been pre-authorized for the email’s selected brand theme. Using an incompatible Fragment will cause rendering issues due to missing styling. While a warning is provided, there is no way to prevent users from doing this.
The architecture can be confusing and it certainly adds management overhead for fragment reuse across different brands.
Comparing classic vs. new templates
New templates are no-code with no code syntax
The new Email Designer allows users to create all assets in a drag-and-drop builder, eliminating the need for a developer. This lack of any template syntax means users are dependent on the New Editor's built-in features for all their design and brand consistency needs.
This poses some challenges, because despite Adobe’s continued work to update the New Marketo Editor, there are still significant gaps in brand control and governance. For instance, implementing custom branded webfonts (for any fonts that are not available on Google Fonts) is still impossible without the manual injection of Custom CSS. With Brand Themes there are new ways to apply branded color palettes and text styling, but for many users there is no way to prevent them from breaking the link to the styles and freely editing them. For most guardrails you are dependent on the limited ‘content locking’ options available, which have some quirks (which we’ll delve into more below).
Updates made to templates do not flow through to emails
While there can be all kinds of annoyances with this process in the Classic Editor, it is possible to make changes to a template and publish a new version. It triggers a Draft in any existing assets using that template, which can be very arduous to review and re-approve, but if you are able to manage the process, it can be done.
In the New Editor, once you use a template, your email forever remains a snapshot in time of the template when you first used it. Updates to the template do not trigger email drafts, and they do not flow through to any emails at all. If you need to update a template, you would need to duplicate it, and then switch over to using the new one everywhere that it was in use. It seems that the recommended option in the New Editor is to use fragments instead of templates.
If you use Brand Themes in conjunction with templates, any themed elements (text and colors) will update if you update the theme.
There is no designated ‘module region’ in templates
The module region in a Classic Editor template is useful for ensuring that each module matches the branding of the template, utilises a full-width layout, and each stacks one on on top of the other, whereas in the New Editor it’s a bit more of a free-for-all: fragments do not have a set size, and they can be placed into any individual column in any layout, but with the addition of Brand Themes there is some added complexity since your fragment and template or email must use the same theme.
Comparing fragments vs. modules and snippets
Fragments are like a combined version of the functionality of both snippets and modules. Below is how they all compare.
Fragments do not belong to any particular template, but must be assigned to Brand Themes
In the Classic Editor, each template has a set of modules that can only be used in that template.
In the New Editor, fragments are more like snippets: they’re free-floating, not tied to a specific template, and can be dropped into any column – similar to how Snippets can be added to any Rich Text area in the Classic Editor. Confusingly however, if you want to use fragments with Brand Themes, you do need to link the theme to the fragment, to avoid rendering issues. There is no guardrail to prevent using an unsupported fragment with a Brand Theme, so it’s up to the user to ensure no errors have been made.
However the alternative is not to use Brand Themes, which can make brand governance difficult because it’s not possible to stop someone from adding an off-brand fragment to a template or email, or vice versa.
It also results in a large quantity of fragments to manage, and there is still no foldering, tagging or custom filtering system for fragments.
Fragment updates behave like no-draft snippet updates
The process of updating fragments is more similar to the snippet update process, which is a definite improvement to the process of updating modules.
Fragments have a Draft and Published status, and by default, fragments behave like No-Draft Snippets. Any updates to them automatically flow through to all templates and Emails that use that fragment, without triggering a Draft.
This is even the case when your fragment contains an editable area that has been modified in emails, which is a huge improvement on the Classic Editor, where modules that contain editable areas are notoriously difficult to update. (Snippets can be preferred in such cases, but it is never a perfect solution: you can’t use the template syntax in snippets, and they must be edited using the standard WYSIWYG editor, an interface that opens the door very wide to easy mistakes like accidentally deleting half a table.)
Fragments can be any size, and be placed anywhere
In the Classic Editor, modules can only be inserted one on top of the other, taking up the whole width of the email. This sounds like a limitation, but it can also be very helpful when you are trying to ensure brand consistency.
However, similar to the way that snippets can be placed into any Rich Text area, New Editor fragments can have any number of columns themselves, but be added to any individual column.
This means a 4-column fragment, carefully laid out according to design guidelines:
Can be dropped into a narrow column:
And end up looking like this:
That’s an extreme example, and honestly, it’s the less extreme forms that this could take that actually give me the biggest chills: those tiny errors that cumulatively make everything veer off brand.
(You will note that the background color is missing, which we discuss in ‘Design Limitations’ below.)
Guardrails are more limited than modules that use template syntax
If you compare a custom-coded Template with the New Marketo Editor, there are not as many opportunities for empowering users to create on-brand content in your modules using custom guardrails.
Marketo's “Email 2.0” Template Syntax, despite its flaws, does offer many mechanisms for coding your own flexible brand guardrails into a module, for example by allowing a user to toggle a logo variation, or select a brand font from a pre-approved dropdown list. You could also utilise global variables to trigger a design change across every module inside a specific template, and much more besides. This allows for creativity that always stays on-brand.
In the New Editor, there’s no template syntax, meaning you can no longer do any of these things, and you are reliant on the built-in mechanisms for brand control. Currently the only available guardrails are the content locking options, which we’ll go into below.
Like snippets, fragments can contain Dynamic Content
As of 2026 this is now possible, and we discuss it further below.
Fragments can’t be shared across Workspaces
While previously you could share snippets across Workspaces, fragments cannot be shared across Workspaces.
Editing fragments vs. editing snippets
Snippets are only editable using the standard WYSIWYG editor in the Classic Marketo editor, whereas Fragments are edited with the New Editor’s drag and drop builder tool. In this sense fragments are an improvement, since the Classic snippet editor is very difficult to use when making anything more than a minor update to text, not to mention how easy it is to accidentally delete a crucial part of the design.
Brand control limitations
The Classic Editor's template syntax empowered developers to build custom guardrails like variables, dropdowns, and boolean toggles directly into a module. The development of the New Editor means we are now dependent on the editor itself to support the same outcomes. And for this the New Editor has introduced two core pillars for brand control: Brand Themes and Content Locking.
Brand Themes
Introduced in Q4 2025, Brand Themes is a feature designed to centralize global styling. Running parallel to fragments and templates, Brand Themes serve as global libraries for visual styles including colors, fonts, spacing, and button attributes (borders, backgrounds, and font sizes). It is important to note that Brand Themes are strictly visual "skins"; they do not govern structural layouts or image-specific configurations.
One of the primary benefits of this system is inheritance: if you update a global Theme, those changes flow through to all assets using it. This allows for centralized management of core brand elements like padding and typography, which is a significant step forward for scalability. However, the system does have several problematic constraints that pose issues to enterprise teams.
Elements in Brand Themes are not configurable
In some cases, there will be too many elements to specify (for example, if you don’t use an H5 heading in your brand) and in others it will be too restrictive: you can only specify 6 brand colors in your palette, and only 3 button styles. There is no way to specify which elements are defined in a Theme.
Brand Themes are not backwards compatible
Perhaps the most frustrating discovery for early adopters is that Brand Themes are not compatible with existing templates or fragments, nor do they support imported content.
If you have already invested significant time in building a library of fragments in the New Editor, you face a "first-mover" penalty: to leverage the benefits of Brand Themes, you must essentially recreate every single asset from scratch. This lack of a migration path or backward compatibility does not instill a great deal of confidence regarding future feature releases.
When creating a fragment or Template, you are forced to choose whether it will utilize Themes at the point of creation. This choice is final; it cannot be revised later.
You must manually map fragments to Brand Themes
To function correctly, a fragment must be manually mapped to specific Brand Themes during its creation. You must only deploy fragments into emails or templates that are using one of the Brand Themes approved for use with that particular fragment.
If you use a fragment which does not support the Brand Theme being used in your template or email, there is a warning that there will be rendering issues if you use it.
In spite of this rendering risk, there is no strict enforcement to prevent this from happening. While a passive warning appears in the builder, nothing prevents the asset from being published.
This restriction also represents a shift in philosophy. The original promise of Fragments was a truly global, "build-once-use-anywhere" asset library. However, by tethering Fragments to specific Brand Themes, Adobe has introduced a model where an asset is only as global as its pre-authorized compatibility list. Instead of a universal library, MOPs teams are left with functionally siloed assets that require constant "earmarking" to remain usable across different brand identities.
This complex dependency is further complicated by Marketo’s current lack of folder structures or tagging for fragments. Management of this situation therefore relies entirely on perfect naming conventions; MOPs teams must manually update fragment names to reflect their theme assignments; a labour-intensive process highly susceptible to human error.
If however you do find the system useful and usable, unfortunately a single fragment can only be associated with a maximum of five Brand Themes. For global organizations managing dozens of brands, this would mean you still need to unnecessarily duplicate an identical layout simply to bypass the theme association limit, exponentially increasing the volume of assets that must be maintained.
Brand Themes are not enough for true brand governance
While Brand Themes help designers maintain consistency, they offer very little in the way of actual enforcement for end users.
Variants are nameless: There is a "Variants" feature within themes strictly for storing alternate color sets, with a limit of six per theme. However these variants cannot be custom-named, meaning users are forced to choose between unlabelled options, increasing the likelihood of selecting the wrong brand palette.
The mix-and-match risk: When a Brand Theme is made available to an end user creating an email, they gain access to the entire library of styles (H1, H2, H3, P1, P2, variants, various button types). There is currently no way to restrict which elements a specific user can access. A user could easily place a primary button where a tertiary one belongs or mix incompatible color variants within a single asset:
Structural gaps: Because Themes have no bearing on layout or structure, you cannot use them to enforce logo sizes, character limits, or specific image dimensions.
Ultimately, for enterprise-scale operations, Brand Themes function more like a "style cheat sheet" than a robust governance tool. If you want to prevent a user from breaking brand structure, you are still forced to rely on the "Content Locking" features, which brings us to the next layer of the governance stack.
Governance and Content Locking
This works a little differently between fragments and templates, so we will delve into both below.
Brand guardrails in fragments - ‘Customizable fragments’
To create customizable fragments, the workflow is that you create the design and layout of your fragment, and then specify certain pieces of content that you would like to be editable when the fragment is used.
You can only do this for images, text and buttons. When the fragment is used, the design and layout will be locked, but end users will be able to populate these aspects of each element:
- For buttons, the button text and the URL
- For images, the image source, image link, and alt text
- For text, text content only with no styling (a plain text field, not a rich text field)
You always have the option not to make any of the fields editable in your fragment, by not doing any of the steps below. That creates a fragment that will remain unchanged wherever it’s used.
How to set up a fragment with editable fields
Go to Design Studio in the New Editor and open fragments in the sidebar. Click Create fragment.
Add a Structure (1:1 Column) and a Button.
Then go to Editable Fields in the sidebar and toggle on “edition” [sic].
Give the component a name, and then toggle on whether you want people to be able to edit the Label and/or the URL.
If you have more complex needs, for example to specify a brand colour variation, or a character limit, unfortunately your only real option is to express the requirement in the title, by writing for example “Headline 10 CHARS MAX”.
Press Save, return to the Fragments list. Go back into your Fragment, and press Publish at the top right corner. Your fragment is now ready to use.
You can repeat the process for text elements and images. When an end-user edits the content of the fragment as they are creating an email, this is what they will see:
End users may break inheritance to edit the fragment at any time
When a user adds the fragment to an email or template, even if it doesn’t contain any editable fields, unfortunately they still get the option to duplicate it, delete it, and ‘break inheritance’ from the parent fragment:
This breaks it apart, allowing it to be edited, and severing its link to the parent fragment, meaning no updates will ever flow through.
Content Locking in templates: “Governance”
There is slightly more flexibility if you lock the content in a template rather than in a fragment. However, the huge downside to locking content down in templates is that there is no inheritance of future updates.
No inheritance
Unlike with fragments, when you publish changes to a template, they are not inherited by emails using that template. No draft is triggered. If you updated a template and wanted to use the latest version, you would need to create a new email using the template.
It’s unclear whether this is an intentional difference between templates and fragments, or perhaps a bug or a gap in the current release.
How to set up a template with content locking
In the New Editor, go into the Design Studio and the Templates [New] area and create a new template.
You can make a top-level choice on the Body element (under the Settings tab) as to whether the entire template should be editable at all, or read only.
No inheritance
Unlike with fragments, when you publish changes to a template, they are not inherited by emails using that template. No draft is triggered. If you updated a template and wanted to use the latest version, you would need to create a new email using the template.
It’s unclear whether this is an intentional difference between templates and fragments, or perhaps a bug or a gap in the current release.
How to set up a template with content locking
In the New Editor, go into the Design Studio and the Templates [New] area and create a new template.
You can make a top-level choice on the Body element (under the Settings tab) as to whether the entire template should be editable at all, or read only.
If you select Content locking, you will further be able to customize this.
After selecting any structure (row), in the Settings tab for that row you can choose whether it should be locked or editable, and this will control whether end users can edit the style of the row by changing the background color, margins, border or background image.
You can then drill down into the elements inside each row, and it’s here where we find the most granular guardrails possible, where you can select from making each element:
- Editable (content and design editable)
- Everything is editable by end users, including all content and styles in the sidebar
- Editable content only which allows edits to the following:
- Buttons: Edit the text, URL, link target (blank, self, parent, top), and button can be deleted or duplicated
- Image: Edit the image, title, alt text, link URL, link target, and image can be deleted
- Text: Edit the text using a rich text-style editor. Insert personalization, use text formatting like bold and italic, insert an image into the text area (!) and optionally delete the text element
- Locked (not editable, but buttons can be duplicated or deleted).
The most eyebrow-raising part is certainly using Text areas set to have editable content only. For some unknown reason, there’s an insert image tool:
Just when you thought it was the end of your nightmares with the Classic Editor letting people insert images into any Rich Text area! Users can go ahead and insert any image they like, which will be inserted at full size:
Body styles are always exposed for editing by the end user
Unless you set the entire template to be non-editable and read-only, it appears that end users are always able to edit the body background colour, viewport color, the overall width of the email, the base font for the entire email, and the margins around the outside of the email, somewhat negating the other guardrails.
You can nest editable fragments in templates but the row must be editable
Updates made to fragments do flow through to templates and to emails made using those templates, and it is possible to nest editable fragments in an otherwise locked-down template, however you do need to ensure you unlock the row that the fragment is contained in. If the row is locked, the fragment will not be editable.
Unfortunately unlocking the row does make the row styles editable as well, and end users can change the background color, background image, border and margins of the row.
Design and rendering limitations
The new builder still feels like quite an immature product, however if you are considering migrating to the New Editor, you may be wondering how all of your design elements would transfer across if you made the move today.
So far, many design features are not possible or quite difficult, and sophisticated designs will be difficult to transfer to the new system.
Below are some design issues that you may encounter.
Buttons don’t render correctly in Outlook for Windows
As many users have reported at numerous events and webinars, there are many significant button rendering issues in Outlook for Windows, like this example below in Apple Mail (left) and Outlook 2021 for Windows (right).
Adobe continues to encourage users to report these bugs, however they’ve persisted for years and give rise to serious concerns about basic rendering reliability not being addressed after all this time.
Background colors
Body background colors don’t render in Gmail, AOL or Yahoo
For some inexplicable reason the templates are coded in such a way that the body background color does not render in these clients. You have to apply background colors to the sections inside your templates instead.
Fragments don’t retain their background color when used
Fragments are no help here: the color applied does not persist when they are used in an asset. In our 4-column fragment example, it has a dark edge-to-edge background on the fragment:
But when you use it in an email, the background does not display:
This would mean you would need to use templates to control the design, and they currently come with a lot of update inheritance issues (see Brand Control Limitations above for more information).
Background images
Can’t use a Body background image
You cannot apply a background image to the overall Body of the email, and there is no ‘Advanced’ CSS tab for the Body element either, meaning there’s not even a way to add it with manual CSS.
Background images do not render in Outlook
While you can add background images to the sections inside the Body, they do not render in Classic Outlook for Windows.
Background position options are limited without coding
The position dropdown only allows the selection of a single value. You can choose from some useful presets such as “Full Width” (cover) and “Full Height” (contain), but for any other choices, it’s not possible for end-users to set both the position and size without having to edit the advanced CSS.
Full-width areas
Not possible to use full-width fragments
For those designs where you may have an edge-to-edge background image or color, it’s difficult to implement those in the fragments and templates system.
The documentation states that this is possible, but unfortunately we weren’t able to reproduce it in testing. It may be a bug or a feature still under development.
You can create full-width areas in your fragment:
However it won’t be inserted into any emails as full-width. Fragments always have to be dropped onto a Column, meaning they can only ever be, at most, the width of the Container, not the width of the Body. You can’t drop a fragment onto the Body.
Buttons
Buttons must have a fixed width and height set
Buttons dimensions are fixed, not flexible.
This means that if you have a button in a fragment or template, and you lock the content so that people can’t edit the button’s visual styles, when someone uses it in an email, if their text is too long it simply overflows the button:
Typography
Key typographical controls are missing, such as line-height and letter-spacing. If you want to enter a line-height, you have to add it to the Advanced Styles panel on a per-element basis.
Fallback fonts are not set for Standard Fonts
There are 19 fonts available, but strangely none of them have fallbacks. This means if you select one of the stranger ones, like “New York” (which is more of a Mac font) on a Windows machine your email will display in a default font like Times New Roman. The font stack CSS just contains a single font for each choice:<div style="font-size:16px;font-family:georgia;">
To fix this you’ll need to manually edit the advanced properties for each text element, and add your own full font stack to each element under the ‘Advanced’ tab.
No support for bulleted lists
Strangely, these are simply not supported in the New Marketo Editor.
Dynamic Content Considerations
In earlier previews of the New Designer, dynamic content (now officially branded as Conditional Content) was a "coming soon" feature. As of Q4 2025, no-code support for dynamic content has officially arrived, but it comes with a couple of caveats.
Dynamic content limited to approved Segmentations only
Conditional Content in the new editor is strictly tethered to pre-approved Segmentations. To create a dynamic element, you click on any structure or component and add a dynamic variant. However, you cannot build logic on the fly; you must select a Segmentation that has already been built, approved, and finalized by a Marketo Admin. This removes the flexibility to create ad-hoc conditional logic directly within the email workspace.
The most significant friction point discovered during our assessment, however, isn't the logic itself but the manual overhead required to manage it.
Manual labelling requirement and lack of validation
When you enable Conditional Content on an element, the editor generates generic placeholders in the sidebar, such as "Variant 1" and "Variant 2." Unlike more modern ESPs or even some legacy competitors, these variants do not automatically inherit the name of the Segment assigned to them.
To actually verify which segment is powering "Variant 2," a marketer must click through a three-dot ellipsis menu and select "View condition" in a separate info window.
This lack of automated naming creates a two-fold risk for enterprise teams:
Manual labor click-work
Marketers are forced to manually rename every single variant across every dynamic element in the email. In a complex, multi-variant campaign, this adds a huge amount of time and mental overhead.
Chance of errors
Because these labels are manually typed, they are prone to human error. There is no "source of truth" connecting the sidebar label to the underlying logic. A marketer could swap a segmentation from "Industry" to "Region" but forget to update the manual label, leading to significant confusion or errors.
So the arrival of Conditional Content is a functional step forward, but the current execution requires a high degree of manual management. If your team relies on complex, high-volume dynamic emails, the New Designer hasn't quite solved the efficiency challenges that define enterprise-scale personalized campaign creation.
Migration considerations
If you have hundreds or thousands of assets built on the existing template, module and snippet structure, what would the migration path look like to the New Marketo Editor?
In Q4 2025, Adobe added a new template import feature designed to expedite the migration process. There is also a plain HTML import path.
We tested both of them out below.
However it’s important to understand the implications for existing emails when importing a new Marketo Template. If you have numerous emails built using an old template, simply importing that template into the New Editor will not automatically convert the existing emails. As confirmed in a recent Adobe webinar, you would have to manually recreate all those emails using the newly imported template. The only alternative is to manually import each existing email individually using the Plain HTML import path (outlined below) – essentially treating each one as a new static HTML template.
Testing the template import process
The new Template Import tool promises a streamlined transition, but for enterprise-grade custom templates, the reality is far more restrictive. Our testing highlighted several critical technical traps:
Selective element import
The tool only imports the mktoContainer and the mktoModules inside it. Most Editor 2.0 templates contain some kind of outer container or wrapper, with a Container area and the modules inside:
When this is imported to the New Marketo Editor, any HTML structure or content outside the primary container is stripped away. This is the view from the template above after import:
This results in a broken layout in clients like Outlook, as the outer "shell" containing crucial table structures and wrapping logic is lost. Below is how the imported template rendered in Outlook for Windows as a Classic template (left) and after importing using the new Template Import in the New Marketo Editor:
Dependency trap
While the tool migrates CSS and HTML from the template's <head>, it does not and indeed cannot distribute these styles to the Fragments you create from the template. This means your new Fragments are permanently "orphaned" from their styling unless they are used specifically with the imported Template – and since there is no tagging or foldering of templates, you will have to manage this relationship manually and by naming assets appropriately.
Zero Brand Theme Support
Imported templates are fundamentally incompatible with Brand Themes, and Fragments that you create from the template are also incompatible.
You cannot apply global styling libraries retroactively; the Brand Theme option must be enabled at the moment of creation from scratch.
The resulting architecture: Editor 2.0 in a new wrapper?
The core promise of the New Editor is a global, reusable Fragment library. However, the Import tool forces you back into a template-specific module system. Because the important styling (mobile overrides, webfont imports, etc.) remains locked in the head of the imported template, the Fragments you save from it will only render correctly when used within that specific shell.
Similar to Brand Themes, this effectively negates the "use anywhere" flexibility of Fragments. You end up with a library of assets that "belong" to specific templates, requiring strict naming conventions (e.g., "TEMPLATE A - Speaker Bio") to prevent users from accidentally using them in incompatible templates—an error that leads to silent rendering failures in the inbox.
Ultimately, there is no convenient migration path that transforms an enterprise-grade legacy template into a modern, theme-enabled asset. You are faced with a choice: settle for a high-maintenance, siloed import or invest the time to recreate your system from scratch to leverage the full power of the new architecture.
Testing the plain HTML import process
There is also a plain HTML import option — and the first point to note is that you should only import truly plain HTML here — this tool has no concept of the Classic Editor’s template syntax. Any usages of the syntax (like variables) will simply appear in the body content as ${variable}.
To import a template, create a new template or email in the New Editor and pick the ‘Import HTML’ option.
After importing your HTML, it can be edited in ‘Compatibility Mode’ which allows you to make simple edits to text, images and links, but not any major changes to the design. It does detect elements quite nicely, for example it detects images perfectly, and only modifies the src property when you use the image picker to select a different image, it doesn’t change or delete any other elements or attributes in the code.
From here, if you are trying to turn an imported template into a templates and set of fragments for reuse, you will need to run the “HTML converter” tool which attempts to turn your HTML into a format that can be edited using the New Editor’s full drag and drop interface, not just Compatibility Mode.
Unfortunately, when you run this, the editor does not detect each container, image, piece of text or button as such – it simply turns every single piece of content into an HTML block.
At this point, if you decide to save this file as a template, it is then possible to set up content locking on each individual HTML block to set whether it should be editable or locked. There is no ‘content editable’ option for HTML blocks. (For more information on this, see ‘Brand control limitations’ above.)
However end users of the template will be editing HTML blocks, which does mean the underlying HTML is “present” as they edit. (When editing HTML blocks as an end user, you are presented with a sort of mini-version of the Compatibility Mode editor.) Additionally, as outlined above, templates are not the best option to use at the moment, since updates made to templates will not flow through to the emails made using them.
After turning our imported file into a template and sending a test email, we noticed some design elements disappeared, for example the body background color was stripped away. There are likely ways to adjust your code and structure before import to avoid some of these issues, but without digging too deeply into it, we can see it’s not currently fully robust. Which, after all, would be a huge ask from any HTML import tool!
Turning back to our imported HTML, if we instead try to use it to create fragments, we can go ahead and create them, but unfortunately their usefulness is extremely limited as it’s not currently possible to set up Editable Fields on HTML Elements inside fragments:
Therefore, after following the current import path, we were not left with a particularly useful set of assets that we could implement with the necessary code quality and brand guardrails.
It does seem that the best approach would probably be to rebuild everything manually using the New Editor, so that you can leverage all of the functionality of fragments and so hopefully be set up to benefit from improvements to the platform that will be released in future versions – if they are backwards compatible, unlike Brand Themes.
Conclusion
While the New Marketo Editor initially showed promise, its two-year track record is proving disappointing. It sounds good on paper, but the persistent lack of robust design and brand guardrails, lack of email rendering stability, coupled with a recent non-backwards-compatible feature release, demonstrates that it's struggling to meet the needs of complex use cases.
The big question is no longer if the New Editor can improve in time, but whether the platform is fundamentally the right choice for forward-thinking teams, especially as the Classic Editor nears retirement.
Our take: If you’re looking to avoid future rework, editor migrations, or design limitations, it’s worth exploring a solution that puts you - not your platform - in control.
That's precisely what we've built at Knak: a modular, no-code creation platform designed for flexibility, scalability, and guaranteed brand consistency. We offer a proven roadmap of consistent innovation that future-proofs your email creation, regardless of future changes to your Marketing Automation Platform or Marketo's own email editor.
