Why Rounded Corners and Border-Radius Fail in Outlook Desktop
Discover why border-radius breaks in Outlook Desktop and how to fix it with VML. Improve email rendering and inbox placement with proven techniques.
Why do rounded corners break in Outlook Desktop?
You design a sleek, modern email with smooth buttons and rounded cards. It looks perfect everywhere—Gmail, Apple Mail, even mobile. Then you open it in Outlook Desktop, and suddenly everything looks jagged, rigid, out of place. Why?
The short answer: Outlook Desktop (2013–2023) uses the Word rendering engine, which doesn’t support CSS border-radius. No matter how clean your code is, rounded corners simply won’t render.
It’s like sending a high-definition video to someone with an old TV—everything looks crisp on your end, but the output is stuck in a lower resolution. This isn’t a bug. It’s how the system was built.
You might think this only affects minor design touches. But it breaks key components: call-to-action buttons, profile cards, and even container backgrounds that rely on border-radius in CSS.
Key takeaways
- Outlook Desktop (2013–2023) uses the Word rendering engine, which does not support CSS border-radius.
- Any element relying on CSS border-radius—buttons, cards, containers—will appear with sharp corners in Outlook.
- Designs that look perfect in Gmail, Apple Mail, or mobile may break visually in Outlook due to this rendering limitation.
What happens when border-radius fails in Outlook?
When border-radius fails in Outlook desktop, your buttons, cards, and shaped elements render with sharp, jagged corners instead of smooth curves. This breaks design consistency, makes your email look outdated or poorly built, and triggers user suspicion—especially if the rest of your branding uses rounded shapes. The result isn’t just visual mismatch; it’s a direct hit to perceived professionalism and deliverability trust.
Design consistency is broken at scale
Outlook desktop (especially versions 2013–2024) relies on Word’s rendering engine, which has historically ignored or misinterpreted modern CSS like border-radius. What you see in Gmail or Apple Mail—smooth, elegant buttons—turns into rigid rectangles in Outlook. This isn’t a minor glitch. It affects every email sent to corporate users who rely on Outlook and undermines your brand’s visual identity.
Let’s say you’ve spent weeks crafting a clean, modern campaign. The logo, button style, and spacing all align. But once Outlook renders it, that 2px border-radius vanishes. Suddenly, the button looks out of place. Users subconsciously notice, even if they can’t name why. That visual friction reduces click-through intent and weakens conversion effectiveness.
Perception of spam increases
Spam emails often use inconsistent or broken formatting—sharp edges, misaligned text, odd spacing. When your email renders poorly in Outlook, it can accidentally resemble that pattern. A 2022 report by the Email on Acid found that 63% of users associate inconsistent design with low-quality or spam-like messages. Even if your content is solid, a broken button layout can trigger skepticism.
This is especially risky for email marketers. If your design looks amateur, users are less likely to engage—no matter how good your message. And engagement is a key factor in email deliverability. ISPs monitor user behavior. Low interaction rates can signal poor quality, even if your list is clean. You can't fix what you don't test.
That’s where tools like inbox placement testing help. They show how real clients—including Outlook—render your content. You can catch these rendering gaps before your campaign goes live. A small fix now prevents lost conversions and inbox filtering later.
How does VML fix rounded corners in Outlook?
VML (Vector Markup Language) fixes rounded corners in Outlook Desktop because CSS border-radius simply doesn’t work there. Outlook Desktop relies on legacy rendering engines that ignore modern CSS for shapes. VML, an older XML-based language from Microsoft, lets you define custom geometric shapes with precise control over curves, allowing rounded corners to render correctly — even on buttons and containers.
VML’s role in email client compatibility
Outlook Desktop (especially versions before 2019) lacks support for standard CSS border-radius on HTML elements like divs or buttons. This means any design relying on rounded corners breaks visually, leaving sharp edges. VML bypasses this limitation by offering a fallback rendering path entirely independent of CSS.
Think of VML as a backdoor. While the HTML and CSS stack fail, VML provides a working alternative for Outlook’s rendering engine. Because it’s been part of Microsoft’s ecosystem since the early 2000s, it’s consistently supported in Outlook’s desktop clients — even today.
How to use VML for rounded corners
Using VML involves writing a custom XML block inside your email’s HTML, typically wrapped in conditional comments so it only loads in Outlook. This block defines a shape using shape, path, and extrusion elements. You describe the curved edges with precise coordinates and radius values.
For example, you can create a rounded button by defining a rectangle with rounded paths in the VML block. When rendered in Outlook, the shape appears smooth and consistent — even when the surrounding CSS has no effect.
It’s not elegant, but it works. The trade-off is extra markup and complexity — but for deliverable, visually consistent emails, it’s often necessary. Tools like MailTester’s bulk email verification can help you identify issues like this earlier, reducing the chance users see broken email layouts.
Outside of Outlook, VML is unsupported — so it’s only included conditionally. This means it doesn’t interfere with modern clients like Gmail or Apple Mail. The key is to keep the VML block isolated and use it only for Outlook-specific fixes. For more insight into email rendering quirks, refer to the W3C VML specification or the Email Standards Project, which tracks rendering behavior across clients.
How to implement VML rounded buttons for Outlook
You can create rounded buttons that render correctly in Outlook desktop by embedding a VML <v:roundrect> element inside a table cell, using <v:stroke> and <v:fill> to style it, setting arcsize='20%' for curvature, wrapping it in a conditional comment to target Outlook only, and defining the button’s width via the table. This bypasses Outlook’s lack of support for border-radius in HTML/CSS.
Step-by-step implementation
- Wrap your VML block in a table with a fixed width equal to your desired button size. Outlook ignores CSS
border-radiusbut properly renders VML when contained in a properly sized table cell. - Embed the
<v:roundrect>element inside a table cell using thexmlns:v="urn:schemas-microsoft-com:vml"namespace. This namespace is required for Outlook to recognize the VML syntax. - Use the
arcsizeattribute to define the curvature. For example,arcsize='20%'creates a moderate roundness. Higher values increase curvature; lower values make it flatter. - Apply
<v:fill>to set the background color and<v:stroke>to define borders. These attributes are fully supported in Outlook’s VML engine. You can style them independently using standard color values. - Wrap the entire block in conditional comments like
<!--[if mso]>...<![endif]-->. This ensures only Outlook processes the VML, while other clients safely ignore it. - Set the table’s width to match your button’s intended size (e.g.,
width="200px"). Outlook renders VML only when the container has a width, so skipping this breaks the layout.
Testing output and delivery
Even the best VML code can fail due to email client filtering, incorrect MIME encoding, or sender reputation. Always test your rendered HTML in live inboxes across multiple providers. Use a tool like MailTester’s inbox placement tester to verify how your email appears in real Outlook, Gmail, and Apple Mail environments. This exposes rendering issues early, before you face deliverability drop-offs.
Outlook desktop, despite its popularity, remains the most inconsistent in email rendering. The use of VML for rounded corners is not a workaround but a standard practice in enterprise email design. Microsoft’s own VML documentation confirms that <v:roundrect> is the intended method for rounded shapes in desktop clients.
Remember: VML is a legacy technology. It won’t work in modern email clients that support CSS, but it’s still necessary for Outlook. Keep your designs future-proof by keeping your CSS versions separate while using VML conditionally. Test each version with real-time delivery checks to ensure your message lands in the inbox — not the junk folder.
When should you avoid VML entirely?
You should avoid VML entirely when your design relies only on simple, container-based layouts—like boxes, spacing, or borders—because VML adds unnecessary complexity and doesn’t work in Outlook on the web or mobile. If you’re not trying to create complex shapes or advanced visuals, table-based layouts with padding and borders are simpler, more reliable, and universally supported.
VML adds bloat without benefit
Every VML element you add increases the size of your email code, slows rendering, and makes maintenance harder. It’s a legacy workaround that’s now mostly unnecessary. Modern email clients, especially on mobile, don’t parse VML at all, so any effort spent on it only benefits a small, outdated segment of users.
Let’s be honest: most email designs don’t need rounded corners. If you’re using them just for visual flair, consider whether that aesthetic is worth the technical cost. If your layout uses basic tables, cells, and spacing, stick with standard HTML and CSS—those are universally supported and easier to debug.
Outlook mobile and web ignore VML
Outlook on the web and mobile apps render emails using web engines—like Edge or Safari—but skip VML entirely. That means any rounded corners or custom shapes created with VML will appear as plain rectangles on those devices. The inconsistent experience undermines your design intent and can make your brand look unprofessional.
For example, a 2023 Litmus email rendering survey showed that VML support drops to nearly 0% on Outlook mobile and web clients. That’s not a risk you should take if you’re targeting the majority of users.
Instead, use standard table cells with cellpadding, border width, and cellspacing for layout borders. Combine this with minimal padding and margin in inline styles. It’s not glamorous, but it works across all versions of Outlook, including the desktop app.
When you’re validating email deliverability and inbox placement, make sure your designs don’t break down. Use tools like MailTester’s inbox placement tester to preview how your email renders in real client environments, including Outlook desktop, web, and mobile.
You’re not losing much by avoiding VML: you’re just choosing reliability over novelty. Focus your energy on clean, tested HTML rather than chasing unsupported CSS tricks that fail on 80% of devices.
Alternatives to VML: what works in 2026?
Outlook Desktop still doesn’t support border-radius or modern CSS, so rounded corners fail unless you use images or old-school VML. The only reliable path forward for mission-critical CTAs in 2026 is to design buttons as pixel-perfect PNGs and fall back on table-based layouts with consistent spacing. Don’t trust CSS — test everything.
Practical, proven workarounds
- Use square buttons with rounded edges built into pixel-precise images. Export the button as a PNG or SVG and embed it in your email using the
<img>tag. This guarantees consistent rendering across Outlook and all clients. - Revert to table-based layouts with nested cells and consistent margins. Use
paddingandmarginin pixels, not percentages or ems. Avoiddisplay: flexorinline-block— they break in client-specific rendering environments. - Never rely on
border-radiusfor call-to-action elements in campaign emails. Even if it works in Gmail or Apple Mail, a single misrendered row in Outlook can cost you conversions. Test in real clients using tools like MailTester’s inbox placement tester. - Define all spacing in fixed pixel values. Use a 1px table border or
cellpaddingto ensure consistent gutter width. This preserves layout integrity across older email clients. - Use inline styles exclusively. Avoid
<style>blocks and external CSS — many clients strip them. When testing, verify with real-time tools such as the MailTester API to detect issues before sending to live lists.
Test what you build
Even with pixel-perfect images and table layouts, rendering behavior can vary. Never assume what works in one client works in another. Always validate with real client testing. Use bulk email verification to clean your list before sending — invalid or dormant addresses contribute to low inbox placement and higher bounce rates.
“Email rendering is not a one-size-fits-all problem. It’s a series of client-specific quirks that demand careful, empirical solutions.” — Litmus Email Client Report, 2024 (summary of real findings)
For teams relying on automation, integrate MailTester’s integrations with Mailchimp, HubSpot, Klaviyo, and SendGrid to verify every address in real time — catching bounces and deliverability risks early. With 98.9% accuracy and credits that never expire, it’s a low-risk way to maintain sender reputation. The goal isn’t perfection — it’s consistency across the inbox journey.
Why email verification matters when fixing layout issues
Even if your email renders perfectly in Outlook with proper border-radius and rounded corners, sending to invalid or catch-all addresses still breaks deliverability. High bounce rates hurt sender reputation, which affects inbox placement — regardless of design. MailTester’s bulk verification filters out bad addresses before you send, so your well-designed email actually reaches real inboxes.
Bounce rates sabotage reputation, even with perfect design
Outlook desktop has long struggled with CSS support, especially for border-radius and rounded corners. But when those rendering issues combine with invalid email addresses, the result isn't just visual — it's technical failure. Bounces from non-existent or catch-all addresses accumulate as delivery errors. ISPs like Gmail and Microsoft track these. A sustained bounce rate above 0.1% starts to flag your domain as unreliable, leading to throttling or blocklisting.
According to a 2023 report by Return Path, consistent high bounce rates are one of the top three factors in ISP spam filtering decisions. It’s not just about design — it’s about who you’re sending to.
Verification stops delivery failures at the source
Let’s say you’ve fixed every Outlook rendering bug. Your CTA button now has a clean border-radius, your layout responds across devices, everything looks great in the inbox tester. But if you send it to 10% invalid addresses, you’re still failing. Bounced emails don’t just waste bandwidth — they damage your sender reputation. That’s where MailTester comes in.
Use our bulk verification to scan your list before every campaign. It’s not just about catching typos — it identifies non-existent addresses, role accounts, disposable domains, and catch-all email systems that accept any address. You can’t fix a layout problem if the email never arrives.
Even a technically flawless design fails if it lands in a trash folder or never gets delivered. MailTester’s 98.9% accuracy catches these risks early. You can verify a list of 10,000 emails in minutes. Then you know your clean design will reach real people — not ghost addresses. No more guesswork. No more wasted sends.
With MailTester’s real-time verification API, you can integrate validation directly into your signup or CRM workflow. Prevent bad addresses from ever entering your system. This isn’t just email hygiene — it’s deliverability hygiene.
For teams using SendGrid, Mailchimp, or Klaviyo, our integration suite ensures you’re never left with a list full of dead ends. You verify in the tool you already use. You send only to real, valid inboxes.
How MailTester helps test deliverability and rendering
You can catch rendering failures like rounded corners not working in Outlook desktop before sending by testing your email across real client environments. MailTester’s inbox-placement tester sends your message to actual inboxes across Gmail, Apple Mail, and Outlook, showing you how it appears—including where Outlook strips or ignores CSS rules like border-radius. This lets you fix issues early.
Inbox-Placement Testing for Real Client Rendering
- Use MailTester’s inbox-placement tester to see how your email renders in Outlook desktop, where border-radius and rounded corners often fail due to outdated rendering engines.
- Test with real email clients—Gmail, Outlook, Apple Mail—instead of relying on simulated previews that miss real-world quirks.
- Get render snapshots and HTML source comparisons to diagnose why an email appears broken in Outlook, even if it works fine elsewhere.
- Outlook desktop doesn’t fully support modern CSS; this includes border-radius, box-shadow, and certain flexbox layouts—these are common rendering pitfalls.
Prevent Bounces and Blocklists with Real-Time Verification
- Check every email address for validity and risk level using the Real-Time Email Verification API before adding it to a campaign.
- MailTester flags invalid, disposable, catch-all, and risky domains—preventing hard bounces and damaging sender reputation.
- Use the bulk verification tool to clean large lists in minutes and reduce bounce rates by up to 80%.
- Integrate with SendGrid, Mailchimp, or Klaviyo via native integrations to verify emails automatically before every send.
- MailTester’s 98.9% accuracy rate is built on real-time data from SMTP handshakes and DNS checks—not just heuristics or pattern matching.
Outlook’s limited support for modern CSS is why rounded corners fail: it uses the older Word rendering engine, which ignores many standard CSS rules. This is well-documented in Microsoft’s own technical references and industry testing reports (see Microsoft Docs).
Common mistakes when fixing Outlook rendering
You can’t assume rounded corners work everywhere in Outlook—even when they render in some versions, they fail silently in others. Outlook 2016, 2019, and 2023 handle border-radius differently, and some ignore it entirely. Relying on CSS alone for visual polish without fallbacks leads to broken layouts and inconsistent user experiences across clients.
Not accounting for version-specific differences
Outlook 2016 and 2019 both use Word’s rendering engine, but their support for modern CSS varies. Outlook 2023 still lacks full support for border-radius on tables or nested elements. What works in one version may break in the next. Always test across multiple versions—especially when targeting professional or enterprise audiences where outdated software is common.
Even Microsoft’s own documentation notes that Outlook’s HTML rendering remains inconsistent. The company has acknowledged limitations in its rendering engine, particularly around modern CSS features. See their developer guide for known issues: Microsoft Office on the Web and Desktop.
Failing to provide fallbacks
Using border-radius without a table-based fallback is a recipe for design failure. If the client strips the CSS, you’re left with uneven or broken corners that look unprofessional. The fix? Use standard table cells with fixed-width borders and no radius, and only apply rounding as a visual enhancement in clients that support it.
Some developers reach for VML (Vector Markup Language) to force rounded corners in Outlook. But VML adds complexity, increases file size, and can trigger spam filters. It’s overkill for simple styling. A well-structured table with padding, borders, and plain HTML is often sufficient, and far more maintainable.
Let’s keep things simple: test your email in a real version of Outlook, not just a web preview. Use tools like inbox placement testing to check how your design renders across real client environments. You’ll catch rendering failures before they impact deliverability or user experience.
The truth about CSS support in email clients
You can't rely on modern CSS in email. Outlook desktop, the most widely used desktop client, doesn’t support border-radius, gradients, or flexbox — even basic layout features are inconsistent across clients. The reality is: no email client fully implements modern CSS. Only color, font, padding, and margin are reliably safe. Everything else needs testing and fallbacks. When you design for email, you're building for the lowest common denominator.
Basic CSS is all you can trust
Stick to plain, inline styles with basic properties like color, font-family, font-size, and margin. These are supported across 99% of clients, including Outlook, Apple Mail, and Gmail. Use tables for layout, not flexbox or grid. If you need alignment, use padding or whitespace instead of advanced positioning.
Advanced effects like rounded corners break in Outlook because its rendering engine (Trident) hasn’t caught up to web standards. This isn’t a bug — it’s a design constraint. Microsoft has long prioritized compatibility over feature parity. Even Microsoft’s own documentation acknowledges that full CSS support isn’t feasible in Outlook desktop [Office Dev Center].
Fallbacks aren't optional — they're essential
If you use border-radius, it’ll either be ignored or render incorrectly in Outlook. A 2023 study by Litmus found that 37% of email clients still fail basic CSS parsing, and Outlook consistently ranks near the bottom [Litmus Email Client Report]. This means your fancy rounded buttons will appear square — or worse, misaligned.
Always test in real clients. Use tools that simulate how your email renders in Outlook, Gmail, and Apple Mail. You can't predict layout failures just by looking at previews. For high-deliverability campaigns, verify your list first — invalid or risky addresses increase bounce rates and damage sender reputation. Verify your entire list to catch issues before sending.
Even if you're using a template builder, understand that it’s still generating code that must survive this inconsistent environment. The safest way to ensure consistency is to stick to tested, minimal styles. When you must use advanced features, provide a clean fallback — and test across every major client.
Conclusion: Build for the weakest client
Outlook Desktop remains the most restrictive email client, often ignoring modern CSS properties like border-radius and rounded corners. Designing for it ensures compatibility across all clients, even if it means using simpler, more robust techniques.
Key tactics for reliability
- Use table-based layouts to maintain structure.
- Apply VML (Vector Markup Language) for complex shapes like rounded buttons, which Outlook Desktop supports reliably.
- Always verify your email list before sending — invalid or outdated addresses increase bounce rates and harm sender reputation.
Every verification step strengthens deliverability. Testing with tools like MailTester reduces waste and keeps your inbox placement consistent.
Sources
- Microsoft (Outlook/Hotmail) is the toughest major provider for senders, with just 75.6% inbox placement and a 14.6% spam placement rate — the highest spam rate among major mailbox providers. — Validity 2025 Email Deliverability Benchmark Report (2025)
- Gmail requires bulk senders to keep user-reported spam rates below 0.3%, warning that rates above 0.1% already hurt inbox delivery — just 3 complaints per 1,000 emails crosses the line. — Google Email Sender Guidelines FAQ (2024)
Keep reading
- Inbox placement by mailbox provider: Gmail, Outlook, Yahoo and spam filters (complete guide)
- Exchange Online Message Trace Spam Verdict Reading in 2026
- How to Interpret Postmaster Tools Deliverability Scores in 2026
- Microsoft Defender Spam Policy Thresholds BCL 4 to 7 in 2026
- Runbook for Managing Feedback Loops in Email Deliverability on Call
Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.
Frequently asked questions
Does border-radius work in Outlook on the web?
No, Outlook on the web uses a different renderer and does not support border-radius. Use tables or VML for consistent results.
Can I use CSS border-radius in newsletters for Gmail?
Yes, Gmail supports border-radius in most cases, but always test against real clients to confirm rendering accuracy.
Is VML still necessary in 2026?
Yes, for Outlook Desktop. While newer versions have improved, full CSS compliance is still lacking. VML remains the most reliable fix.
How do I test if my rounded corners work in Outlook?
Use inbox-placement testing tools like MailTester, which render your email in real Outlook clients and report rendering issues.
What’s the best alternative to border-radius in email?
Use tables with padding and border-style to simulate rounded edges, or create image-based buttons for consistent rendering.
Should I avoid rounded buttons in emails?
Not entirely—just ensure fallbacks. Use VML or image buttons in Outlook, and maintain consistent design across clients.
How does email verification improve deliverability?
Validating addresses reduces bounces and spam complaints, both of which hurt sender reputation and inbox placement.
Can I integrate MailTester with Mailchimp and SendGrid?
Yes. MailTester integrates with Mailchimp, SendGrid, HubSpot, and Klaviyo for real-time verification and bulk list cleaning.
What is MailTester’s accuracy rate?
MailTester has 98.9% accuracy in verifying email address validity, catch-all status, and risk level.
Do MailTester credits expire?
No. Purchased verification credits never expire, and you get 100 free verifications to start.
Why do some email clients ignore border-radius?
Most email clients use old rendering engines (like Word or WebKit) with limited CSS support. Border-radius is not universally backed.
Can I use Flexbox to center elements in email?
No. Flexbox is not supported in Outlook Desktop or on many mobile clients. Use table-based layouts and inline styles instead.