The Complete Guide to HTML Email Signatures (2026)

Email clients are not web browsers. They strip out CSS files, ignore external stylesheets, and interpret code differently than Chrome or Safari. The culprit is how email clients render HTML—most of them (especially Outlook) use Microsoft Word's rendering engine instead of a real HTML engine. This means div-based layouts, flexbox, and CSS Grid simply don't work. Tables, however, predate CSS and remain the most reliable way to control layout in every email client. You might think tables are outdated for web design, but email is the exception. Tables give you cell-by-cell control over width, height, padding, and alignment. When you place your name, title, contact info, and logo in table cells, you control exactly where they appear in Gmail, Outlook 2010, Outlook on Mac, and Apple Mail. Without tables, your signature becomes a jumbled mess on half the clients your recipients use. The table approach involves wrapping your entire signature in a `<table>` tag with a single row. Inside that row, you create cells for different content blocks—a logo cell on the left, contact information in a cell on the right, maybe a banner across the top. Each cell has explicit width and height values. You control spacing with cellpadding and cellspacing attributes, not margins or padding that email clients ignore. The border attribute stays set to zero because you want invisible structure, not visible grid lines. This structure remains consistent because every email client respects the table HTML standard. You avoid positioning tricks, relative/absolute layouts, and media queries—all things that fail unpredictably in Outlook. Instead, you build your signature like you're filling in a structured form with clear boundaries. This constraint actually forces better design decisions. You can't rely on fluid spacing or clever CSS tricks, so you focus on readable text, clear hierarchy, and deliberate visual separation. Your logo size is fixed. Your contact buttons have explicit dimensions. Your text columns have defined widths. This predictability is a feature, not a limitation. When you submit your signature through SignatureFox, the generator builds this table structure automatically, with proper nesting and cell attributes already optimized. You get clean HTML that works because it respects how email clients actually function, not how you wish they functioned.

Most email clients strip out `<style>` tags completely. Gmail deletes them. Outlook ignores them. Apple Mail sometimes respects them, but inconsistently. This means any CSS you write in a style block disappears, and your signature appears unstyled. The workaround is inline styles—CSS written directly on HTML elements using the style attribute. This approach works because inline styles travel with the element itself. You write `<td style="background-color: #f0f0f0; padding: 10px; font-family: Arial, sans-serif;">` and that styling stays attached to the cell no matter which client opens the email. However, not all CSS properties work inline. Email clients only respect a subset of CSS: colors, fonts, font sizes, font weights, line heights, text alignment, padding, margins (sometimes), borders, and background colors. They ignore positioning (position, top, left), transforms, animations, box-shadow, and most layout properties beyond basic padding and margins. This means your inline styles need to be conservative and tested. You set font-family to web-safe fonts like Arial, Helvetica, Verdana, Georgia, or Times New Roman—never custom fonts that require @import or external font files. You specify fallback fonts: `font-family: Arial, Helvetica, sans-serif;` ensures that if Arial fails, Helvetica becomes the backup. You use hex colors like #ffffff or #333333, never color names like 'white' or 'red' because some clients don't recognize them. You set text-align to center, left, or right—never justify. You specify padding in pixels (10px, 15px) and avoid shorthand when possible because some older Outlook versions misinterpret it. You include line-height values (1.5, 1.6) to control spacing between text lines. You avoid using margin for spacing in email because Outlook strips margin declarations. Instead, you use padding on the containing cell or table. Background colors go on table cells, not text, because text background colors often fail. Border properties work but keep them simple: `border: 1px solid #cccccc;` works reliably, while border-radius (rounded corners) fails in Outlook. When you use SignatureFox, the generator applies inline styles throughout your signature HTML, testing each property against known client support. You get styles that render consistently without guesswork or trial-and-error.

Most email signatures include a logo, headshot, or brand image. If you link to those images using a standard URL—like `<img src="https://example.com/logo.png">` —you create a dependency. The image file must exist on your server forever. If you move it, delete it, or your domain goes offline, the image breaks in every email you ever sent. Recipients see a broken image icon. Your signature looks unprofessional. Base64 encoding solves this by converting your image file into a long text string that lives inside the HTML itself. Instead of linking to an external file, you embed the image data directly: `<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">`. The image is now self-contained. It never breaks. Recipients see it immediately without waiting for an external server to load. The base64 string is long—a small 200x200 logo might be 5KB or 10KB of encoded text—but email clients handle it without problems. This embedded approach also eliminates tracking vulnerabilities. When images load from external servers, senders can track when recipients open emails by logging image requests. Base64 images don't create server requests, so they're more private. Converting images to base64 requires tools. You export your logo as PNG or JPG, then use an online converter or command-line tool to generate the base64 string. You paste it into the img src attribute. One constraint: keep images small. Large images create large base64 strings, which can hit email size limits. A logo should be under 50KB. A headshot should be under 100KB. These size limits are generous for typical professional images. You also need to specify image dimensions in pixels: `<img src="data:image/png;base64,..." width="200" height="200" alt="Logo">`. The width and height attributes prevent the client from guessing and distorting your image. The alt attribute provides text if the image fails to load—it's both an accessibility requirement and a fallback. Never use percentage widths for embedded images because email clients interpret them unpredictably. Always use fixed pixel dimensions. When you build your signature through SignatureFox, the generator embeds your logo and headshot as base64 automatically. You upload the image files, and the tool converts them, optimizes them, and places them in the HTML. You never manually touch base64 code. The result is a signature that includes your images, forever, without broken links or external dependencies.

Building an HTML signature for 'email in general' doesn't work because no such thing exists. Gmail renders differently than Outlook, which renders differently than Apple Mail. Outlook 2010 behaves differently from Outlook 365. Yahoo Mail strips different tags than Proton Mail. The only way to know your signature actually works is to test it across these clients. Many professionals skip this step and deploy a signature assuming it's fine, then months later discover their alignment is off in Outlook or their colors look wrong in Apple Mail. Testing doesn't require expensive tools. You need access to the clients your audience uses. If your company is 70% Outlook and 20% Gmail, test those two thoroughly. If you work with creative clients on Apple Mail, test on Mac and iOS. If you run a consulting firm with mixed clients, test all major clients. For each client, you follow the same process: send yourself a test email with your signature, open it in that client, and check for visual breaks, misaligned elements, cut-off text, broken images, wrong colors, and formatting issues. Gmail typically renders HTML faithfully, so table layouts work well there. Outlook can be problematic with padding, margins, and certain CSS properties. Apple Mail respects most styles but sometimes ignores line-height or applies default spacing you didn't intend. Yahoo Mail and Proton Mail usually handle basic table layouts but fail on advanced styling. You document what you observe in each client. If your signature looks good in Gmail but breaks in Outlook, the problem is usually padding or margin declarations on cells, or perhaps conditional comments you forgot to include. Outlook has older CSS support, so you sometimes need Outlook-specific fixes using conditional comments: `<!--[if mso]>` blocks that only Outlook reads. If your headshot appears misaligned, check the vertical-align property on the cell—it might need to be 'top' or 'middle' depending on adjacent content. If colors look off, verify you used hex codes, not named colors. If your signature looks different on mobile, remember that email clients don't use media queries reliably. Mobile rendering depends on the client resizing text and reflowing tables, which varies widely. You test on actual devices if possible—iPhone, Android, and iPad—not just desktop clients. When you use SignatureFox, the HTML is pre-tested against major clients during generation. However, you should still do a personal spot-check in your actual email clients to confirm it matches your expectations and that your specific logo and contact details render correctly in your exact environment.

Now you understand the foundations: tables for layout, inline styles for formatting, base64 for images, and testing across clients. Building your actual signature involves decisions about structure, content, and styling. Start by defining what information your signature must contain. Most professional signatures include: name, job title, company name, email address, phone number, and maybe a website or social media link. Some add a logo and headshot. Some include a company address. Some add a brief company description or tagline. Decide what matters for your role. A freelancer might skip company address. A corporate employee might include it. A recruiter might add social links. Once you know what to include, sketch the layout. Most signatures use a two-column approach: logo and headshot on the left (about 80-100 pixels wide), contact information on the right in a narrower column (200-300 pixels). Some use a banner across the top with company branding, then content below. Some stack everything vertically on one column. Sketch it on paper or in a simple graphic tool. Visualizing the structure helps you decide table dimensions before you write code. Choose a color scheme. Most professional signatures use your company's brand colors or neutral grays and blacks. Pick one or two accent colors for links or dividers. Use hex codes. Test that text contrast meets readability standards—dark text on light backgrounds or light text on dark backgrounds. Avoid light gray text on white backgrounds, which strains eyes. Choose fonts. Stick to web-safe fonts: Arial, Helvetica, Verdana for sans-serif; Georgia, Times New Roman for serif. Use font-size values between 11px and 14px for body text, maybe 16px for your name. Larger text makes signatures hard to scan. Smaller text becomes unreadable. Set line-height to 1.5 or 1.6 for readability. Decide on padding and spacing. Most signatures leave 10-15 pixels of padding around content cells, 5 pixels between rows. These values prevent everything from appearing cramped while keeping the signature compact. Your signature should be under 6 inches tall when viewed in Outlook or Gmail. Size your images. Logos usually appear 80-100 pixels wide (automatically tall proportional to width). Headshots appear 80-100 pixels wide. Larger images balloon your signature size. Add social media icons if your company uses them, but embed them as small base64 images (20-30 pixels wide), not as text links. Now you have your structure, colors, fonts, and sizing. The next step is creating the HTML. SignatureFox generates this for you—you input your information, upload your images, choose your styling preferences, and the tool creates production-ready HTML. But whether you generate it through SignatureFox or build it manually, the underlying approach remains the same: table-based structure, inline styles, base64 images, and tested across your actual email clients. When you receive your HTML file from SignatureFox, open it in a text editor. You'll see the table structure, inline styles, and embedded images. You'll recognize the patterns: style attributes controlling colors and fonts, img tags with base64 src attributes, and table cells arranged precisely. You can edit it if needed—change your phone number, update your title, adjust colors—because the HTML is clean and modular. Most edits are straightforward: find the text you want to change, replace it, save the file. For style changes, modify the hex color codes or font sizes in the style attributes. The HTML stays valid as long as you don't break the tag structure. Once you're happy with the HTML, follow SignatureFox's install guide to place it in your email client. Gmail and Outlook have built-in signature management where you paste the HTML directly. Apple Mail requires a few extra steps. The guide walks you through each client. After installation, send yourself test emails and check how your signature renders in each client you tested earlier. You might notice small adjustments are needed—maybe spacing feels off, or a color looks different on Mac. Make those edits and reinstall. Once it's perfect, you're done. Your signature is now consistent, professional, and bulletproof.