ValidEmailChecker

Free HTML Email Signature Generator

Generate an HTML email signature, edit the code, and see which CSS works in which mail client — table vs div, inline styles vs style block. Free, no signup.

Free Email Signature Builder
Outlook-safe HTML
20 templatesLive previewFree, no signupRuns in your browser
Build my HTML signature

Click anywhere on the preview to open the full builder.

Reference Matrix

CSS support across major mail clients

What works in Gmail web doesn't always work in Outlook desktop. This is the short version of the Litmus and Campaign Monitor reference matrices, narrowed to the properties signature designs depend on. Click any row for the most-common gotcha.

CSS propertyGmail webOutlook (Win/Word)Outlook web/MacApple MailiOS Mail
background-color
background-image
border-radius
box-shadow
display: flex
margin (on <p>)
padding (on <td>)
font-family
font-size (px)
text-align
border (on <td>)
@media queries
prefers-color-scheme
CSS animations
Full Partial None

Full per-property data: caniemail.com · Litmus · Campaign Monitor

Why an HTML email signature is a different problem

If you searched for "html email signature generator" you probably want one of three things: (1) the raw HTML to hand-edit before pasting it somewhere, (2) HTML to wire into a CRM or transactional email template, or (3) reference data on which CSS works in which mail client. Most generators on Google's first page assume the first thing, treat the keyword as a synonym for "email signature generator", and ship you a form-builder with a copy button.

This page is for the other two. The canonical Email Signature Generator handles the consumer flow. This generator gives you an editable HTML code panel that round-trips back into the live preview, a per-CSS-property compatibility matrix across major mail clients, and toggles for table-based vs div-based output and inline styles vs `<style>` blocks. No other free tool on the SERP does any of those.

Generate, then edit: the live HTML code panel

After you fill in the form, the generated HTML appears in a panel below the preview. Edit it directly — change a `padding`, drop in a tracking pixel, swap the font stack, add a custom CSS class for an external stylesheet to pick up later. The preview updates as you type.

This pattern matters because every other free generator on the SERP is one-way: form in, copy button out, no path back to the code if you want to tweak it. If your final signature lives in a CRM template editor or an ESP's template variables, you need the raw HTML to hand-edit before it can go in. The "build first, hand-edit after" flow is the wedge.

The CSS-in-email problem

CSS support in email clients is not consistent and not getting better. Some clients support the 2020 spec; Outlook 2016 still strips half of CSS2. There are two reference matrices everyone uses:

Our generator embeds a compact version of this data alongside the code panel: a table showing which of the most common ~30 CSS properties work in Gmail web, Gmail mobile, Outlook desktop (Word), Outlook web, Apple Mail, iOS Mail, Yahoo Mail, and Thunderbird. Hover any property to see the underlying support level (full, partial, none) per client.

Table-based vs div-based signatures

The default output uses nested `<table>` elements for layout, because Outlook desktop (still ~30% of business email opens) renders only the table-based layout consistently. Most HTML email frameworks (MJML, Foundation for Emails) target tables for the same reason.

For modern-client-only audiences — internal email at a Gmail-only Workspace, transactional mail that never reaches Outlook, beta-test signatures — `<div>`-based layout with `display: flex` works and produces cleaner markup. Our generator has a toggle: tables (default, max compatibility) or divs (modern only, ~40% smaller HTML). The toggle updates the code panel and the preview in place so you can compare the two outputs.

When to pick divs over tables

Pick divs only if you know your recipient client. Internal Gmail Workspace where every team member uses Gmail web? Divs work. Marketing email going to a list with 30% Outlook desktop users? Tables. Default to tables unless you have proof your audience is modern-only.

Inline styles vs a <style> block

Most email clients strip `<style>` blocks from the `<head>` of email HTML, or sometimes strip them from the `<body>` too. Gmail web strips `<head>` entirely. So the safe default for HTML email is inline styles on every element: `<td style="padding:8px; color:#222;">…</td>`.

A few clients preserve `<style>` blocks (Apple Mail, some Outlook web variants, Thunderbird). For those, a `<style>` block with `@media` queries lets you add responsive behavior and dark-mode overrides that inline styles cannot express. Our generator offers a toggle:

  • Inline styles only (default) — maximum compatibility, no responsive behavior
  • Inline + `<style>` block — adds a media-query block for clients that honor it, falls through to inline styles in clients that strip it

Most ESPs (Mailchimp, SendGrid, Klaviyo) auto-inline `<style>` blocks at send time. If you are sending through an ESP, the toggle does not matter — pick whichever produces more readable source.

MSO conditionals and Outlook's Word rendering engine

Outlook 2007 through Outlook 2019 + Microsoft 365 on Windows renders email HTML through Microsoft Word's engine, not a browser. Word strips most modern CSS. The escape hatch is MSO conditional comments — HTML comments that the Word engine parses as live HTML while every other client treats them as ordinary comments.

<!--[if mso]>
  <!-- Outlook reads this as HTML -->
  <table cellpadding="0" cellspacing="0" border="0">
    <tr><td>Outlook-only content</td></tr>
  </table>
<![endif]-->

<!--[if !mso]><!-->
  <!-- Outlook ignores this; everyone else renders it -->
  <div>Modern HTML for non-Outlook clients</div>
<!--<![endif]-->

Common uses in signatures: VML-wrapped rounded buttons (Word ignores `border-radius`), table-based fallback layouts for div-based modern markup, and the `OfficeDocumentSettings` block that fixes the 120 DPI Windows scaling bug. Our generator includes the MSO blocks in the output where they materially improve the Outlook render. For the deep Outlook-specific tool, see our Outlook Signature Generator which also produces a downloadable `.htm` file for the Outlook Signatures folder.

Dark mode: media queries, color-scheme, and Outlook's inversion behavior

Dark mode in email is messy. Different clients implement it three different ways:

  • No transformation (Gmail web on Chrome, mostly) — your light-mode CSS renders unchanged even when the user has set dark mode at the OS level.
  • Partial inversion (Apple Mail, iOS Mail, some Outlook variants) — the client inverts background colors but tries to preserve image colors. Black text on transparent backgrounds stays black, which becomes invisible.
  • Full inversion (Outlook for Windows desktop dark mode, Gmail mobile dark) — every color is inverted aggressively. Pure white (`#fff`) flips to pure black (`#000`); pure black flips to pure white.

Three defenses work across most clients:

  1. Set both `color` and `background-color` on every text node. Clients that invert backgrounds without inverting text are the most common source of unreadable signatures. Specify both so the contrast survives.
  2. Use transparent PNGs for logos and photos. A logo with a white background stays white in dark mode; a transparent PNG floats on whatever background the client picks. Same for headshots.
  3. Add a `@media (prefers-color-scheme: dark)` block in `<style>` for clients that honor it (Apple Mail, modern Outlook web). Override specific colors that need different values in dark mode.

Reference: Litmus's Ultimate Guide to Dark Mode for Email Marketers is the most-cited public write-up. Our compatibility matrix flags `prefers-color-scheme` support per client so you know which clients honor the override.

Targeting Outlook.com dark mode specifically

Outlook.com (web) uses a non-standard attribute `[data-ogsc]` on its dark-mode `<body>` element. Selectors like `[data-ogsc] .my-class { color: #fff; }` inside a `<style>` block let you override colors only when Outlook.com inverts. Apple Mail, iOS Mail, and the modern Outlook clients honor `prefers-color-scheme`; Outlook.com is the holdout that needs the `[data-ogsc]` workaround.

Hosting images for email signatures

Three options, each with different tradeoffs:

MethodProsCons
Public CDN URL (imgbb, Cloudinary, AWS S3)Light HTML, works in all clients, no per-message overheadRecipients with images blocked see placeholder until they click Show Images
Embedded as base64 data URLNo network request, image always showsInflates HTML 33% past binary size; Word strips long base64 strings; can exceed Gmail 10K limit
CID (Content-ID) attachmentImage always shows; no external requestImage attached to every outgoing email; raises spam score; complex to set up in non-Outlook clients

Our generator defaults to public CDN hosting via imgbb. Upload an image in the Photo or Logo section and the tool POSTs it to `/api/upload-image`, which forwards to imgbb and returns a public URL we embed in the signature HTML. The URL is short, stable, and adds no per-message overhead.

For images you already host yourself, paste the URL directly into the image URL fields and skip the upload entirely. Make sure the URL returns HTTP 200 to anonymous requests (test in an incognito window) — corporate CDNs that require authentication will fail for recipients.

Deliverability and signature size

A heavy signature hurts in three places:

  • Gmail's 10,000-character signature limit. Gmail rejects signatures over 10K characters of HTML. See the Gmail Signature Generator page for the deep dive — short version: avoid base64 images and Word/Docs paste.
  • Gmail message clipping at 102 KB. Gmail clips entire messages over 102 KB into a "[Show trimmed content]" link. A heavy signature pushed onto a thread of 20 replies stacks up fast. Image weight is the dominant factor — host images externally, not inline.
  • Multipart/alternative obligations. Per RFC 2046, every HTML email should ship with a plain-text alternative. Most ESPs auto-generate this, but if you are wiring HTML signatures into a custom transactional mail service, make sure the plain-text branch includes a stripped-down version of your signature.

Installing the HTML signature in major clients

Quick paths per client — for full walkthroughs, see the dedicated Email Signature Generator install section.

  • Gmail web: Settings (gear icon) → See all settings → General → Signature → Create new → paste HTML → set "FOR NEW EMAILS USE" and "ON REPLY/FORWARD USE" → Save Changes.
  • Outlook desktop (cleanest path): download the `.htm` from our Outlook Signature Generator, drop into `%APPDATA%\Microsoft\Signatures\`, restart Outlook.
  • Outlook web / Outlook.com: Settings (gear) → View all Outlook settings → Mail → Compose and reply → paste HTML → check both default boxes → Save.
  • Apple Mail (macOS): Mail → Settings → Signatures → pick the account → click + → name the signature → paste HTML → drag onto the account name to set default.
  • Salesforce / HubSpot / other CRMs: paste the inline-styled HTML into the user's signature field. Most CRMs preserve inline styles but strip `<style>` blocks — use the "inline only" toggle for CRM-bound signatures.

Wiring into an ESP or transactional service

If you are embedding the signature in a Mailchimp / SendGrid / Postmark / Resend template, paste the HTML into a template variable and reference it from every message template. Most ESPs auto-inline `<style>` blocks at send, but test before relying on it — pick the "inline only" toggle for guaranteed safety.

Skip hand-writing the HTML

Our free builder produces table-based, inline-styled, cross-client signature HTML with MSO conditional fallbacks for Outlook. Standard .html download for Gmail/Apple Mail and an Outlook-optimized .htm for the Windows Signatures folder.

Build my HTML signature

Related Free Tools

Signature Generator

Build a professional email signature in under 2 minutes. 20 templates, instant HTML and rich-text export for Gmail, Outlook, and Apple Mail.

Open tool

Gmail Signature

Build a Gmail signature that survives Gmail's 10,000-character limit, mobile rendering, and dark mode. Generate, copy, paste into Gmail Settings.

Open tool

Outlook Signature

Build an Outlook signature with MSO conditional comments, fixed DPI scaling, and a downloadable .htm file you drop directly into your Signatures folder.

Open tool

Email Footer Generator

Build a legally compliant footer for your marketing emails. CAN-SPAM, GDPR, CASL, PECR — required fields validated, multi-language.

Open tool

Frequently Asked Questions

Dev and marketer questions on table vs div, inline vs style block, MSO conditionals, dark mode, and ESP integration.

Yes. After the form generates a signature, the HTML appears in an editable code panel below the preview. Change anything — padding, font stack, custom CSS classes, embedded tracking pixels — and the preview updates as you type. This is the main differentiator versus other free generators, all of which are one-way (form in, copy button out, no path back to edit the code).

Less than you would hope. Outlook desktop (still ~30% of business email opens) renders only a subset of CSS2, ignores most positioning, and strips `border-radius`, `box-shadow`, and CSS animations. Gmail web supports more, but strips `<head>` and `<style>` blocks. Apple Mail and iOS Mail are the most permissive. Our compatibility matrix shows ~30 common properties across 8 mail clients so you know what will and won't survive before you ship.

Tables for cross-client compatibility, divs only for modern-client-only audiences. Outlook desktop's Word engine reliably renders nested tables; div-based layouts using `display: flex` break there. If your signature will reach Outlook users at all, default to tables. If you control the recipient client (internal Gmail-only Workspace, transactional mail to mobile-only audiences), divs produce lighter, cleaner markup. Our toggle lets you compare both outputs.

Inline CSS is the safe default — most clients strip `<style>` blocks, and Gmail web strips the entire `<head>`. Some clients (Apple Mail, modern Outlook web, Thunderbird) preserve `<style>` blocks, which lets you use `@media` queries for responsive and dark-mode behavior that inline styles cannot express. Our generator offers both. ESPs like Mailchimp and SendGrid auto-inline `<style>` blocks at send time, so for ESP-bound signatures either option works.

An HTML comment in the form `<!--[if mso]>…<![endif]-->` that Microsoft Outlook's Word rendering engine parses as live HTML, while every other email client treats it as a plain comment and ignores it. You need MSO conditionals to ship Outlook-specific fallbacks (table-based layout when divs fail, VML for rounded buttons that Outlook can't render via CSS, the `PixelsPerInch=96` block that fixes the Windows DPI scaling bug). Our generator emits these in the output where they materially improve the Outlook render.

Yes, with caveats — dark mode in email is fundamentally inconsistent across clients. We do three things: set both `color` and `background-color` explicitly on every text node (so the contrast survives partial inversion), recommend transparent PNGs for logos (so they work in light and dark), and offer a `@media (prefers-color-scheme: dark)` override block for the clients that honor it (Apple Mail, modern Outlook web). The compatibility matrix flags dark-mode support per client.

Yes, though there's no built-in bulk mode in this version. The pattern: generate one canonical template via the form, copy the HTML, then template-replace the per-user fields (`{{name}}`, `{{title}}`, `{{email}}`, etc.) using your CRM's template engine or a one-off script. A native bulk CSV mode that outputs an HTML file per row is on the roadmap.

MJML and Foundation for Emails are full HTML email frameworks — they produce entire email layouts (header, body, footer, multiple sections) with their own markup languages that compile to email-safe HTML. Overkill for a single signature. Our generator is signature-specific: 20 templates, a config form, the editable HTML panel, and the compatibility matrix. For a quick custom signature you want now, this is faster. For a complete marketing email layout, MJML is the better tool.

Email HTML carries a lot of overhead: inline styles on every element (Gmail strips `<style>` blocks, so every property has to live on the element), nested `<table>` markup for Outlook compatibility, and explicit width / height / alignment attributes for clients that ignore CSS equivalents. A typical signature with photo and 4 contact fields renders to ~2,000–3,500 characters of HTML for ~50 characters of visible text. That's normal.

Limited. Email clients vary in font support: Gmail web honors web fonts from Google Fonts; Outlook desktop ignores `@font-face` entirely and falls back to whatever the system has installed. The safe path is a font stack that lists your preferred font first, then web-safe fallbacks: `font-family: "Inter", -apple-system, "Segoe UI", Arial, sans-serif`. Outlook will skip Inter and land on Segoe UI; iOS will use -apple-system; everything else falls back to Arial.

Upload an image through the Photo or Logo field and the tool POSTs it to `/api/upload-image`, which forwards to imgbb (a free public CDN). You get back a stable public URL embedded in the HTML. If you already host your images (CDN, S3 bucket, company file server), paste the URL directly into the URL field — make sure the URL returns 200 to anonymous requests so recipients can load it.

Mostly. The generator outputs semantic markup where it can (`<a>` tags for links, alt text on images, sufficient color contrast in default templates), and the templates pass WCAG 1.4.3 contrast minimums when used as designed. Custom edits can break that — if you change text color to something that fails contrast against the background, the generated HTML is no longer accessible. The canonical [Email Signature Generator](email-signature-generator) has a deeper accessibility section covering Section 508 and the WCAG details.

Still have questions?

Contact our support team →

Your Next Campaign Deserves
a Clean List

Stop guessing. Stop bouncing. Start reaching the people who actually want to hear from you.

Get Started Free View Pricing

200 free credits · No credit card required · Results in minutes