"You Know HTML, Right?" — The Quiet Frustration of Every Frontend Developer Asked to Build Emails
It starts innocently enough. A Slack message. A quick chat. Someone from marketing or management leans over and says: "Hey, can you put together an HTML email for this campaign? You know HTML, right?"
And just like that — the frontend developer becomes the email developer. No context. No tools. No budget. Just an assumption that HTML is HTML, and if you can build a web page, you can build an email.
If you've been here, you know exactly what comes next.
The Assumption That Causes the Problem
The logic seems reasonable on the surface. HTML emails are written in HTML. Frontend developers know HTML. Therefore, frontend developers can build HTML emails.
What this logic completely ignores is that email development and web development are entirely different disciplines — with different rules, different constraints, and different failure modes.
On the web, you write modern CSS and it works. Flexbox, Grid, custom properties, animations — browsers have largely standardised. You test in Chrome, maybe Firefox, and you're done.
In email, none of that applies.
Gmail strips your <style> blocks and rewrites class names. Outlook — still used by millions — renders HTML using Microsoft Word's engine. Not a browser. Word. That means no border-radius, no flexbox, no background-image CSS. Apple Mail handles things differently again. And every client behaves differently on mobile versus desktop.
The email you carefully crafted that looks perfect in your browser? It arrives broken in Outlook. The layout collapses on Android. The fonts don't load in Gmail. The button looks fine on desktop and completely wrong on iPhone.
This isn't a skill problem. It's a tooling problem. And it's a knowledge problem that nobody warned you about.
The Budget Problem
Here's where it gets worse.
When a frontend developer runs into a cross-browser web issue, there are free tools everywhere. Browser DevTools, Can I Use, MDN — the entire ecosystem is free and accessible.
When a frontend developer runs into a cross-client email issue, the professional tools cost money. Real money.
Litmus starts at $99/month. Email on Acid isn't cheap either. These are tools built for dedicated email marketing teams with real budgets and real volume.
The frontend developer who just got handed a one-off email task doesn't have that budget. And when they ask for it, the answer is almost always: "We don't really need to pay for that, can you just test it yourself?"
Test it yourself. On what? By sending it to every email client you can think of, on every device you have access to, and hoping you've covered enough ground?
This is the trap. The company expects the problem solved. The company won't provide the tools to solve it. And the frontend developer is left stuck in the middle.
What Actually Happens
In most cases, one of three things:
Hours of trial and error. Sending test emails to Gmail, Outlook, iPhone. Making a change, sending again, checking again. Repeat until it looks acceptable on the clients they happened to test. The clients they didn't test remain unknown.
Nobody caught the Outlook rendering issue. Or the Gmail clipping problem. Or the font fallback that made the whole email look wrong on Android. The email lands in 50,000 inboxes looking nothing like it was designed to.
Most free tools just render your HTML in a browser — which, as covered above, tells you almost nothing about how it will actually look in a real email client.
None of these are good outcomes. All of them are predictable outcomes of giving someone a task without giving them the right tools.
The Specific Things That Catch Developers Off Guard
If you're new to email development, here are the things that will bite you:
Outlook's Rendering Engine
Outlook for Windows uses the Microsoft Word rendering engine to display HTML emails. This means modern CSS simply doesn't work. No border-radius — your rounded buttons become squares. No flexbox — your carefully laid out columns collapse. No background-image CSS — your hero section background disappears.
You need VML and MSO conditional comments to work around Outlook, and nobody teaches you that in any web development course.
Gmail Clipping
Gmail clips emails larger than 102KB. If your email — including all inline CSS — exceeds that size, Gmail will clip it with a "View entire message" link. Everything below that cut gets hidden. If your unsubscribe link is at the bottom, it disappears. Users can't see it. That's a legal and deliverability problem, not just an aesthetic one.
Style Stripping
Gmail removes <style> blocks in many contexts. CSS you wrote carefully in a style tag gets stripped entirely. Your fallback fonts kick in. Your layout shifts. Everything you thought was handled — isn't.
Dark Mode
Most email clients now default to or support dark mode. White backgrounds become black. Light text on white — invisible. Your logo with a white background becomes a white square floating on a dark background. Dark mode testing isn't optional anymore.
Image Blocking
Many email clients block images by default. If your email is image-heavy with no alt text, your recipients see a wall of broken image icons. Alt text isn't just accessibility — it's your fallback content when images don't load.
None of this is obvious if your background is web development. All of it matters enormously when your email lands in a real inbox.
Why This Problem Persists
Companies underestimate email development because the output looks simple. It's just an email. How hard can it be?
The complexity is invisible until something breaks. And when it breaks, it breaks at scale — after the send button has been pressed, in inboxes that can't be recalled.
By that point, the question shifts from "why didn't we give the developer proper tools" to "why did the developer send a broken email." The developer absorbs the blame for a systemic failure.
This is why frontend developers who get handed email tasks need proper tooling from day one — not as a luxury, but as a basic requirement for doing the job they've been asked to do.
What Actually Helps
The minimum a frontend developer needs to build emails responsibly:
- A proper preview tool. Not just a browser tab — a tool that applies real email client rendering rules so you can see how Gmail, Outlook, Apple Mail, and mobile clients will actually display your email. MailViewr does this for free, with no signup required.
- A compatibility reference. Know which CSS properties work where before you write them. Resources like caniemail.com document email client support the same way caniuse.com documents browser support.
- A testing workflow. Before any email goes out: preview across clients, check dark mode, verify the email is under 102KB, send a test to at least one real inbox. Five minutes of checking prevents email disasters.
- Basic knowledge of email-specific workarounds. Tables for layout. Inline CSS as a baseline. MSO conditional comments for Outlook. Font fallback stacks. These aren't advanced techniques — they're email fundamentals that any developer working with email should know.
You Shouldn't Have to Figure This Out Alone
The "you know HTML, right?" problem isn't going away. Companies will keep handing email tasks to frontend developers. Budgets for proper tooling will keep getting rejected.
But at least the tooling gap can be closed for free now.
MailViewr exists specifically for this situation — the developer who needs to test an HTML email properly, without a corporate subscription, without creating an account, without waiting. Paste your HTML, see exactly how it renders across Gmail, Outlook, Apple Mail, and mobile clients, get a compatibility score, and catch the issues before they reach a real inbox.
It won't fix the assumption that HTML is HTML. But it gives you what you need to do the job right — regardless of whether your company thinks you need it.
Start Testing Your Emails for Free →