The guide
A button in an email is a link wearing a costume, and one mail program cannot see the costume
Why the most clicked object in a newsletter is still built from table cells, a drawing language from 1998 and a comment that only one program reads.
- 2007 year one desktop mail program began drawing HTML with a word processor
- 17% arcsize for an 8 px corner on a 48 px tall button, by the usual rule
- 4.5:1 contrast floor for ordinary text, WCAG 2.2 Level AA
- 44 by 44 px enhanced target size, WCAG 2.2 Level AAA
- 8 px largest border the support data lists for the word processor engine
Read the full guide Fold the guide
Open a marketing email and the thing you are meant to press is almost never a button. It is a link. It has a color behind it, some room around the words and perhaps rounded corners, and all of that is costume. Underneath sits the oldest interactive element the web has, an anchor with an address.
On a web page the costume takes three lines of style. In an email it can take thirty lines of markup, two languages and a comment that most programs ignore. The reason is not that email designers are careless. It is that an email is opened by programs its author never chose, and one widely used family of them does not draw HTML with a browser at all.
The word processor in the inbox
The 2007 release of Outlook on Windows stopped drawing messages with the rendering engine of a web browser and began using the engine of the word processor shipped in the same office suite. Anything that engine did not handle was simply no longer supported. Messages written in the word processor looked right. Messages written for browsers lost whatever the word processor had never learned.
A community project keeps a public table of what each mail program supports, feature by feature, with the date each feature was last tested. Its data is published under the MIT License, which is why it can be quoted here. For border-radius it lists that desktop program as not supported in every version from 2003 to 2019, in a test dated 9 March 2021. Across the forty-one program and platform pairs in that file, twenty-eight support the property fully.
Padding tells a subtler story. The same data marks padding as partial in the 2007 to 2019 versions, with the note that it is only supported on table cells. A link is not a table cell. Give a link generous padding and, in that one program, the padding is not applied: the colored area collapses onto the words.
Borders are capped as well. The data records that a border there cannot be bigger than 8 px. Each of these facts is small. Together they explain why a button that needs three lines on the web needs a strategy in email, and why the data’s own dates matter: support changes, and a table read today describes only what was tested then.
Three ways to dress a link
The simplest technique puts the link inside a table cell and lets the cell carry the color. The HTML Standard says plainly that tables must not be used as layout aids on web pages, and it lists the signs of a layout table: a role of presentation, a border of zero, cell padding and spacing of zero. Email markup uses exactly those signs, deliberately, because a table cell is the one box every mail program sizes and colors reliably.
In that first technique the link is padded so that the area around the words is part of the link. Where padding on a link is honored, the whole button responds to a tap. Where it is not, the cell still shows its color and its height, but only the words are the link. A reader who taps the colored margin gets nothing. That is the trade: the least code, and a smaller target in one program.
The second technique replaces padding with borders. The link gets thick borders in the same color as its background, so the colored area is built from the link’s own box. A border belongs to the element, so every colored pixel opens the address. The cost is the 8 px ceiling noted above, and corners that are still square wherever border-radius is ignored.
The third technique is the one people mean by the word bulletproof. It writes the button twice. One copy is an ordinary styled link. The other is a drawing: a rounded rectangle described in Vector Markup Language, a format published by the World Wide Web Consortium in May 1998 as a Note, a submission offered for review. The archived reference describes its roundrect element as a predefined round rectangle shape, and gives every shape an href attribute: when the shape is clicked, the address loads.
The two copies are kept apart by a conditional comment. The first copy sits between <!--[if mso]> and <![endif]-->. To any program that follows the HTML Standard this is one long comment, skipped whole. The word processor engine is commonly reported to read inside it; no document this essay may cite states that, so treat it as established practice. A second pair of comments hides the ordinary link from that engine and from nothing else.
One number worth deriving
A drawn rectangle does not take a corner radius in pixels. It takes an attribute named arcsize, a fraction. Here the documents and the practice part company, and it is worth being honest about that.
Take a button 220 px wide and 48 px tall with corners of 8 px. Established practice divides the radius by the shorter side: 8 over 48 is 0.167, written 17%. A fully round end, a radius of 24 px, comes out as 50%, and practice treats that as the maximum.
The 1998 note and the archived reference both say something else. They define arcsize as a percentage of half the smaller dimension, with 100% making the short side a semicircle. Read literally, the same 8 px corner is 8 over 24, or 33%. The two readings differ by a factor of two. A generator cannot settle the question from inside a browser, because a browser never draws the shape. The only fair answer is to state both, default to the rule in long use, and check the result in the program itself.
That worked example can be reproduced in the tool above: 220 by 48, radius 8, and the measured line reads arcsize 17%. Switch the rule and it reads 33%.
Buttons that are links, for everyone
Because the costume is only costume, the accessibility questions are the questions of any link. The words must say where it goes. The Web Content Accessibility Guidelines ask that the purpose of a link be clear from its text, alone or in context. A label that reads “Click here” fails a listener who is moving from link to link. The address matters too: a web link needs its protocol, and an address for mail has a scheme of its own, mailto, with a published syntax.
The words must also be legible. The guidelines define contrast as a ratio of relative luminances and set the floor for ordinary text at 4.5:1, or 3:1 for large text, which they define as 18 point, or 14 point bold. White on a strong red-orange, #ffffff on #b93815, measures 5.77:1. White on a paler orange, #ff8a65, measures 2.31:1 and fails both floors.
Size matters to a thumb. The enhanced target size criterion, at Level AAA, asks for 44 by 44 px in CSS pixels; the minimum criterion at Level AA asks for 24. A 48 px tall button clears both. A link dressed in a thin 28 px strip does not clear the first.
Real text has a quieter advantage. When pictures are switched off, or simply fail to load, a button that is a picture becomes an empty box. A button made of text, a background color and table cells is still a button with the pictures off, and it can be read aloud. In the hybrid the label appears twice in the code, once per copy, yet each program reads one copy only, so it is announced once.
Dark mode, and the limits of a preview
Dark mode is where intent and outcome drift furthest apart. CSS offers a color-scheme property and a matching meta element, by which a document says it can be shown light or dark, and a media feature, prefers-color-scheme, that reflects the reader’s wish. In the support data, the meta tag is read by two of forty-one listed pairs, in a test dated September 2026. The media feature fares better, eighteen of forty-three. Fewer than half.
So a dark rule is a courtesy to the programs that read it, never a guarantee. It is commonly reported that some programs recolor a message on their own when they find no instruction. The practical defense is modest: choose a button color that keeps its contrast against both a light and a dark surround, and do not rely on a head style block, since some clients strip it.
No preview can replace the inbox. A browser shows how a browser draws the markup. It can imitate a missing property by leaving that property out, and such an imitation is useful for catching a button that collapses without padding. It is still a simulation. The drawn shape in the comment is invisible to every browser.
The honest test is a real message. The format of one is public: a few header lines, a blank line, then the body, with alternative versions of the same content in plain text and HTML separated by a boundary line. Save such a file, open it in the mail programs your readers use, and look. Then press the button with your thumb.
Sources
Every source consulted for this guide. Links checked October 11, 2026.
- HTML Standard, 13 The HTML syntax WHATWG
- HTML Standard, 4.9 Tabular data WHATWG
- HTML Standard, 4.5 Text-level semantics WHATWG
- HTML Standard, 15 Rendering WHATWG
- Vector Markup Language (VML) World Wide Web Consortium
- VML RoundRect Element MicrosoftDocs win32 repository on GitHub
- VML ArcSize Attribute MicrosoftDocs win32 repository on GitHub
- VML TextBox Element MicrosoftDocs win32 repository on GitHub
- Can I email: support tables for HTML and CSS in emails Remi Parmentier and contributors, on GitHub
- Can I email feature data: border-radius Remi Parmentier and contributors, on GitHub
- Web Content Accessibility Guidelines (WCAG) 2.2 World Wide Web Consortium
- CSS Color Adjustment Module Level 1 World Wide Web Consortium
- Media Queries Level 5 World Wide Web Consortium
- RFC 5322: Internet Message Format Internet Engineering Task Force
- RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies Internet Engineering Task Force
- RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types Internet Engineering Task Force
- RFC 6068: The 'mailto' URI Scheme Internet Engineering Task Force
- Microsoft Outlook Wikipedia