Tailwind CSS Email Width, Spacing & Container Best Practices

A strong HTML email container is fluid below a fixed maximum, usually around 600 pixels, with predictable side padding and table-based fallbacks for Outlook.

Tailwind makes the source concise, but the exported HTML still needs explicit widths, cell padding, and overflow-safe math.

Recommended container pattern

<div class="mx-auto w-full max-w-[600px] bg-white">
  <div class="px-5 py-8 sm:px-10 sm:py-12">
    ...
  </div>
</div>

The compiler should turn the structural container into output shaped like:

<table role="presentation" width="600"
       style="width:100%;max-width:600px;background:#ffffff">
  <tr>
    <td style="padding:40px 32px">...</td>
  </tr>
</table>

The HTML width supports older clients; CSS allows the table to shrink.

Is 600px required?

No. It is a practical default, not a standard.

Use a narrower container for short transactional messages and a slightly wider one when data tables genuinely need room. The correct width balances:

• desktop readability;
• phone behavior;
• line length;
• image assets;
• Outlook fallback; and
• your real content.

Do not widen the email merely to fit a long heading.

Use padding for major spacing

Table-cell padding is dependable for:

• outer gutters;
• section interiors;
• column gaps; and
• button surfaces.

Margins can still be used on text after inlining, but reset defaults explicitly and test Outlook.

<td style="padding:32px 24px">
  <h1 style="margin:0">Receipt</h1>
  <p style="margin:16px 0 0">Thanks for your order.</p>
</td>

Define a spacing scale

Use a small pixel-based rhythm, for example:

• 4px for tight icon relationships;
• 8px for compact labels;
• 12px for related controls;
• 16px for paragraph or card spacing;
• 24px for groups;
• 32px for sections; and
• 40–48px for major vertical breaks.

The exact values matter less than consistency. A limited scale also produces smaller, more predictable output.

Avoid accidental overflow

A 600px row with two 300px cells plus 24px padding on each cell is wider than 600px.

Choose one:

• subtract gutters from column widths;
• place padding inside nested tables;
• use a dedicated gutter cell;
• split gap across cells; or
• let the compiler calculate safe widths.

Always test at the narrowest supported viewport.

Tailwind gap utilities

gap-* is convenient source syntax, but output may need cell padding. A compiler should translate the layout deliberately.

For critical rows, inspect whether the generated gutters:

• preserve outer alignment;
• remain equal;
• collapse correctly on mobile; and
• avoid adding width.

Read tables vs. Flexbox vs. Grid.

Mobile padding

Use compact unprefixed padding and a larger desktop enhancement:

<div class="px-5 py-8 sm:px-10 sm:py-12">...</div>

The mobile value must be inline. The sm: value stays in a media query. If the query is removed, the compact version remains useful.

Full-bleed sections

Place a full-width background table outside the constrained inner table:

<table role="presentation" width="100%" bgcolor="#0f172a">
  <tr>
    <td align="center">
      <table role="presentation" width="600" style="width:100%;max-width:600px">
        <tr>
          <td style="padding:32px 24px;color:#ffffff">...</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

This creates edge-to-edge color while keeping readable content width.

Spacer components

Do not stack empty paragraphs or repeated line breaks.

Use section padding or a dedicated spacer component that compiles to a stable table row with explicit height and line-height. Keep spacer values on the same scale as component padding.

Width rules for images

Give an image an intrinsic width and fluid style:

<img src="..." width="600" class="block h-auto w-full" alt="...">

The output should include max-width:100% and height:auto. For icons and logos, preserve the intended fixed width instead of stretching to the container.

Common mistakes

• using 100vw inside email;
• relying only on max-width for Outlook;
• adding padding that makes columns exceed the row;
• using random spacer values;
• shrinking text to compensate for a wide layout; and
• forgetting mobile outer gutters.

Frequently asked questions

What is the best HTML email width?

Around 600 pixels is a dependable default. Adjust only when real content and client tests justify it.

Should email widths use pixels or percentages?

Use both: a percentage for fluid behavior and a pixel maximum or width attribute for the desktop container.

Is max-w-[600px] enough?

Not for every Outlook version. Add an explicit table width or compiler-generated fallback.

Should spacing use margin or padding?

Use cell padding for major structure. Use explicit margins for simple text spacing after testing.

Constrain width, standardize rhythm

Email layout becomes easier when width and spacing stop being one-off decisions.

Choose one container strategy, one spacing scale, and a small set of section patterns. Let Tailwind express them in source and require the compiler to produce width-safe table markup.