Bloat in new email editor (cut off in gmail) | Community
Skip to main content
Level 2
January 21, 2026

Bloat in new email editor (cut off in gmail)

  • January 21, 2026
  • 4 replies
  • 122 views

I created two versions of the same email:

  • One using the old editor, built from my own custom template with HTML compiled from MJML

  • One using the new WYSIWYG Email Designer

The version built in the old editor is roughly half the size of the new one. With the new editor, I’m constantly hitting Gmail’s 100 KB clipping limit and having emails cut off, even when the visible content is minimal.

What’s especially confusing is fragment behavior. When I update a fragment to delete content, the email actually gets larger, sometimes by 30 KB or more. From what I can tell, fragment updates are appending duplicate CSS and redundant markup instead of removing it.

I’ve seen mentions that the old editor may be sunset in 2026, and I’m about to build a new nurture program. I’m concerned about being forced onto the new editor when it’s already difficult to keep emails under Gmail’s size limit.

Am I missing something here, or are others seeing the same behavior with the new editor?

    4 replies

    Disha_Goyal6
    Community Advisor
    Community Advisor
    January 21, 2026

    Hi ​@604jimmy I am facing the same issue with the new editor.

    Disha_Goyal6
    Community Advisor
    Community Advisor
    January 22, 2026

    I think the issue is coming due to the number of lines . Drag and drop editor shows more lines of code and because of this, it is clipped in email editor.

    Michael_Florin-2
    Level 10
    January 21, 2026

    I wonder how I can reply with a quote… And can I edit other people’s posts?

    @604jimmy I don’t believe the current editor will be sunset anytime soon. Thousands of Marketo customers - most likely pretty much all of them - are on the current templates and current emails and have no intention of switching - yet. That switch would cost immense amounts of time and money, without actually improving their customer’s experience. So I’d be shocked if there was any plan of sunsetting.

     

    Jasbirka
    Level 5
    January 22, 2026

    Hi

    Level 1
    February 9, 2026

    Are you using themes or one of the pre-built templates? 

    I realized the pre-built sample templates that Marketo offers is built using in-line styling. This duplicates CSS for every single element. We switched to themes, rebuilt ALL our templates (although lost of styling functionality) and it significantly helped. 

    HOWEVER, there is still a large amount of html bloat that could be cleaned up by Marketo. We’re seeing a ton of blank paragraph tags being added and can’t figure out why. 

    Dave_Roberts
    Level 10
    February 18, 2026

    You’re 100% correct, there’s a TON of bloated code in the new editor. This is an “architectural feature” that’s built into the codebase of the new email editor -- you and I might call it a bug or an oversight, but it is what it is. It’s becoming clear that the goal of the new email editor is to provide some shiny, easy to use tool for folks who don’t know much about email development and it’s really starting to show how well they’re aligned with their audience. 
     

    I’m in alignment with ​@Michael_Florin-2 that the EM 2.0 editor won’t be going away anytime soon. There’s a lot of hype surrounding this topic but I haven’t seen anything official from Adobe about a sunset date (someone please correct me if I’m wrong). I also have strong doubts that it’ll go anywhere this year b/c the new editor is a major step backwards and I can also see this causing a huge rift with existing customers who demand better from their emails and insist on using the EM 2.0 system. For what it’s worth, FreeForm landing pages are still a thing and those were put together in the days before responsive coding was a normal thing. 

     

    Overall, the bigger issue you’re running into here has more to do with the Acrite editor tool and the email codebase and how those are applied to the editor. There’s ALOT of hard work to do to build a tool which works around issues like duplicate CSS and redundant markup. It’s much easier to pile things on top of each other and write and overwrite stuff than it is to surgically update a codebase following a user’s input. In this case, it’s a case of the easy road for the shiny solution that’s rushed to market instead of the hard work that represents the sort of step forward that EM 1.0 > EM 2.0 represented. In principle, the big difference from my POV is that we’re moving from an open system (EM 2.0) into a closed system (EM 3.0) and the new system contains an inferior code structure than what most folks are using today and there’s nothing anyone can do about it.