Centering Buttons Across Outlook and Gmail
Center a call-to-action reliably: why margin auto fails in the Word engine, the align attribute plus text-align pair, and centering a fixed-width VML button.
A button centred with margin: 0 auto sits centred everywhere except Outlook on Windows, where it hugs the left edge — and a button centred with an align attribute drifts in a client that ignores it. This guide covers the combination that centres reliably, and the additional step a fixed-width VML button needs.
Root Cause: Three Centring Mechanisms, None Universal
Centring is normally a solved problem, which is why the email failure is surprising. Three mechanisms exist and each is honoured by a different set of clients.
margin: 0 auto requires the engine to compute the remaining space and distribute it, which the Word engine does not do for table elements. It is ignored, and the element falls to the left.
text-align: center centres inline content within a block, so it works on an anchor inside a cell but does nothing for a nested table, which is a block-level element in every engine that implements the box model properly.
The align="center" attribute is presentational HTML, predates CSS, and is honoured by essentially every email client including the Word engine — but it is invalid in strict HTML and is stripped by some rewriting clients.
The reliable pattern uses all three, applied to the elements each one actually affects, so that whichever the client honours produces the same result.
The Exact Fix
<!-- The outer cell centres inline content: this handles an anchor-only button
in every client, and is the fallback if the attribute is stripped. -->
<tr>
<td align="center" style="text-align:center;padding:24px 0;">
<!-- The button table carries align="center" as well, because a nested
table is block-level and text-align on the parent does not move it.
Outlook 2016-2021 honours the attribute and nothing else here. -->
<table role="presentation" align="center" cellpadding="0" cellspacing="0" border="0"
style="margin:0 auto;">
<tr>
<td align="center"
style="border-radius:6px;background-color:#a53860;text-align:center;">
<a href="https://example.com/confirm"
style="display:inline-block;
font-family:Arial,sans-serif;font-size:16px;line-height:24px;
mso-line-height-rule:exactly;
color:#ffffff;text-decoration:none;
border:14px solid #a53860;border-radius:6px;">
Confirm your order
</a>
</td>
</tr>
</table>
</td>
</tr>Three declarations do the work, and each covers a different failure. align="center" on the nested table is what centres it in the Word engine. margin: 0 auto centres it in the engines that implement it and is redundant elsewhere. text-align: center on the outer cell catches the case where the nested table is stripped entirely by a rewriter, leaving the anchor as inline content in a cell.
The align attribute must be on the nested table, not only on the outer cell. A cell's alignment applies to its inline content; a nested table is not inline content, so the outer cell's attribute does not move it.
Variant: Centring a VML Button
A VML roundrect button has a fixed pixel width, which makes centring harder rather than easier: the shape does not participate in normal flow the way an anchor does.
<td align="center" style="text-align:center;">
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:w="urn:schemas-microsoft-com:office:word"
href="https://example.com/confirm"
style="height:48px;v-text-anchor:middle;width:220px;"
arcsize="12%" stroke="f" fillcolor="#a53860">
<w:anchorlock/>
<center style="color:#ffffff;font-family:Arial,sans-serif;font-size:16px;">
Confirm your order
</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://example.com/confirm" style="display:inline-block; /* … */">
Confirm your order
</a>
<!--<![endif]-->
</td>The VML shape is centred by the containing cell's align attribute, because the shape behaves as an inline-block within it. What does not work is margin: 0 auto inside the shape's style — VML does not implement margin at all, and adding it produces no effect and no warning.
The <center> element inside the roundrect is doing something different: it centres the label text within the shape, not the shape within the cell. Both are required, and confusing them is the usual reason a VML button ends up with left-aligned text inside a correctly centred shape.
Variant: Full-Width Buttons on Mobile
A centred fixed-width button often reads better as a full-width button on a phone, which is a media-query change rather than a centring one.
<style>
@media only screen and (max-width: 480px) {
/* Stretch the button table and its anchor; the centring declarations
become inert because there is no free space left to distribute. */
.btn-table { width: 100% !important; }
.btn-anchor { display: block !important; text-align: center !important; }
}
</style>Because the Gmail Android app may strip the query, the centred fixed-width version must be acceptable on a narrow screen on its own — which in practice means keeping the button no wider than about 260px so it fits a 320px viewport with margin.
Centring Two Buttons Side by Side
A single centred button is straightforward; a pair of buttons — a primary action and a secondary one — is where the pattern most often breaks, because the two must be centred as a group rather than individually.
The mechanism that works is a wrapper table containing one row and two cells, itself centred by the same attribute-plus-CSS combination. Centring each button separately in its own full-width cell produces two buttons each centred in half the width, which looks like a layout error rather than a deliberate pair.
<td align="center" style="text-align:center;">
<!-- The GROUP is centred; the buttons inside sit at their natural widths. -->
<table role="presentation" align="center" cellpadding="0" cellspacing="0" border="0"
style="margin:0 auto;">
<tr>
<td style="padding-right:8px;">
<!-- primary button table -->
</td>
<td style="padding-left:8px;">
<!-- secondary button table -->
</td>
</tr>
</table>
</td>The padding split across the two cells rather than applied as a margin between them is deliberate: margin between table cells is unreliable in the Word engine, while cell padding is honoured. Splitting it in half keeps the pair visually centred, since an 16px gap applied entirely to one side would shift the group by 8px.
On mobile the pair should usually stack, and the stacking must keep the buttons centred individually once they are on their own rows. That is a media-query change on the cells' display, and because the Gmail Android app may strip the query, the side-by-side arrangement must still fit a 320px viewport — which in practice caps each button at about 140px, or argues for a single primary action with the secondary offered as a text link instead.
That last option is usually the better design as well as the more robust one. Two competing buttons in a transactional message is a decision the reader did not ask to make, and reducing to one primary action removes both the layout problem and the ambiguity.
Pipeline Integration
Centring belongs in the button component, not in each template. A component that always emits the attribute-plus-CSS combination makes it impossible to produce a button that centres in some clients and not others, which is the realistic failure — a developer copying a button from one template into another and dropping the outer cell's attribute in the process.
Add a compiled-output assertion that every button table carries align="center" alongside its inline margin. It is a one-line regex and it catches the omission at build time rather than in an Outlook screenshot a week later.
Validation and Deployment Checklist
Frequently Asked Questions
Is the align attribute deprecated?
It is not part of modern HTML, but email is not modern HTML — every client parses it, and the Word engine honours nothing else for this purpose. Validators will flag it; that is a cost worth accepting, and it is the same trade already made by cellpadding, cellspacing and bgcolor throughout an email template.
Why does my button centre in the preview but not in Outlook?
The preview is a browser, which honours margin: 0 auto. Outlook does not, so a button relying on margin alone centres in every environment a developer normally looks at and fails in the one they cannot open locally. This is the single most common instance of the pattern, and it argues for a client render check before release rather than for a different centring approach.
Does align="center" affect the text inside the button?
On the containing cell, yes — it centres inline content, which includes the anchor's label. On the button table it centres the table itself. That overlap is convenient rather than confusing in practice, since both are what you want, but it is why the declarations appear redundant when they are not.
Should the button be centred or left-aligned?
Centred is conventional for a single primary action and reads as a deliberate call to action. Left-aligned works better when the button follows a paragraph and belongs to it, since it keeps the reading line intact. What matters more than the choice is consistency across templates, which is another argument for the decision living in the component.
Related
- Bulletproof Email Buttons — the border-padding pattern this centring wraps
- VML Rounded Button for Outlook — the fixed-width shape with its own centring rules
- Outlook Rendering Fixes — why the Word engine ignores computed layout
- Responsive Email Layouts — the breakpoint the full-width variant uses
← Back to Bulletproof Email Buttons