SendWithSES Drag-and-Drop Email Designer: HTML email editing with no compiler in the middle

An email editor extracted from an SES sending service

The project started inside SENDUNE, an AWS SES based sending service formerly called Send With SES, and the README says it was built for that use before being open sourced. The repository is small in a way that matters: the tree has four entries, a `.gitignore`, `LICENSE`, `README.md` and a single `email-designer/` directory. There are no published GitHub releases and no separate changelog, so the repository is the component rather than a released library of components.

GitHub reports TypeScript as the language, an MIT license, 2,307 stars, 143 forks and only 2 open issues. The fork-to-issue ratio is unusual, and it lines up with how the package is distributed: through npm rather than through tagged releases, which means the open issue tracker is not where the activity lives.

The live demo is at designer.sendune.com, and the README makes a point of it: you can design a template there and send yourself a test email. That matters more than it sounds, because the hardest part of any HTML email project is not authoring the HTML, it is confirming what the receiving client did to it.

Three editing modes over the same output

The component supports three template types, and the README describes them as covering transactional and marketing email with unlimited saved templates. There is a drag and drop designer for starting from scratch, an HTML code editor for reusing templates you already have or writing them by hand, and a plain text mode that the README labels for minimalists.

The decision that matters technically is the rejection of intermediate languages. The README says plainly: no intermediate code wranglers like MJML. Most HTML email tooling in this space asks you to write a component-based dialect that compiles down to table-based HTML, because table layout is what email clients actually support. By editing the output directly, this designer removes a compilation layer, which means there is no build step to wire into your pipeline and no mismatch between what the designer shows and what the compiler emits.

The tradeoff is that you lose the safety net. With a component dialect, a structural mistake tends to produce a compile error or a broken component rather than a subtly invalid table. Editing raw HTML means the editor will happily accept markup that Outlook renders badly, and nothing in the component checks that for you.

Wiring it into an Angular app and handling images yourself

The package installs from npm or yarn under an Angular scoped name:

npm install @send-with-ses/ng-email-designer

There is also a StackBlitz project, which the README notes is built on Angular 15 while claiming the same process should work on other versions. The component is used with template type, template value and three outputs, two of which exist so your application can take over image handling:

<lib-email-designer #emailEditor class="px-0"
        [type]="selectedTemplateType" [template]="selectedTemplate"
        (imageSelectionTriggered)="onImageSelectionTrigger($event)"
        (imageUploadTriggered)="onImageUploadTrigger($event)"
        (emailContentChanged)="onEmailContentChange($event)"
        >
</lib-email-designer>

That shape is the whole integration story, and it is honest about what is missing. The README says to use a cloud storage of your choice, naming AWS S3, Cloudflare R2 and GCP Cloud Storage, and that you should implement the image upload functionality and provide it to the library. So the editor delegates image upload to the host application by design. You get the selection and upload events and you supply the storage, which is the right call for a self-hosted component and means you will write that part yourself.

Theming through CSS custom properties

Visual integration is done with two stylesheet imports and a set of CSS variables. Both files are imported into a global styles file:

@import '../node_modules/@send-with-ses/ng-email-designer/src/lib/theme.scss';
@import '../node_modules/@send-with-ses/ng-email-designer/src/lib/email-editor.css';

The colour scheme is then driven by custom properties on `:root`, which the README says you can change as you like to match your site's UI:

 :root {
    --sws-icon-color: #ccc;
    --sws-icon-hover-color: #555;
    --sws-header-background: #eee;
    --sws-header-text-color: #555;
    --sws-border-color: #ccc;
 }

Only five variables are exposed, all of them about chrome rather than content: icon colour, icon hover, header background, header text and border. There is no variable for fonts, spacing or palette inside the canvas. That is consistent with the project's stated position, since the canvas renders your HTML and your HTML should carry its own styling. Read it as a thin tool surface around a content surface rather than a design system.

The design rules are borrowed, and the opinions are the author's own

The README credits three sources for the layout fundamentals and links each: Ted Goas of Cerberus Email, Nicole Merlin of Email Wizardry and Mark Robbins of Good Email Code. That attribution matters because those are the references practitioners actually use for email-safe table layout, and citing them is a shortcut to knowing the approach is conventional rather than invented.

The last section of the README is a different register entirely, titled minimal rationalism, and it is the most quotable part of the project. The claims are blunt: you are designing an email rather than a website, and if you want fine-grained controls like line heights you are in the wrong place. The more you nitpick the design, the more likely it breaks in email clients, with the parenthetical that more moving parts means more breakages. Transactional emails are best delivered in plain text, which connects directly to the plain text template type.

There is also a market observation worth taking seriously: the top three email service providers control roughly 80 percent of the market and can break you. And a delivery observation that no amount of tooling fixes, which is that avoiding spam folders is mostly a function of content, and neither technology nor the pedigree of your sending service rescues unsolicited mail.

Where this sits against the usual email editor choices

The comparison to make is not against other designers so much as against the two dominant workflows. If your team already writes MJML or Handlebars templates in a repository and reviews them in a pull request, a browser designer is a different tool for a different moment, and this one will feel thin because it does not version, diff or parameterize anything. If your team ships email from a service and needs a designer your marketing colleagues can operate without a deploy, the three modes and the portable HTML output are the appeal.

The portability point deserves emphasis because it is the feature that survives any change of provider. The README's democratic framing is that you save the HTML output as a template and use it with any email service provider. Nothing in the output format ties you to SES or to SENDUNE. Switching sending vendors means changing the transport, not rebuilding the templates.

Two facts to keep separate as you evaluate. The README calls the tool truly open source and truly free, and GitHub reports an MIT license, which is consistent. But the project is a single directory with no releases and a very quiet issue tracker, so the practical risk is not licensing, it is that the component tracks whatever Angular version you are on without a published compatibility matrix. Check the StackBlitz project against your own Angular major before committing.

Editorial conclusion

This designer is best understood as the part of an email sending service that happened to be worth releasing. Its strongest feature is that it edits real HTML directly, so the output is portable to any provider and there is no intermediate compilation step to debug. Its strongest opinion is that most email design features are liabilities, and the optional-reading section argues that at length. What you will not find here is test sending, template versioning or a headless API, so a team that needs those still needs its own infrastructure. Start with the live demo at designer.sendune.com, and if the drag canvas does not fit your workflow the HTML editor mode is the same component.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SendWithSES/Drag-and-Drop-Email-Designer on GitHub