Gmail Signature vs Outlook Signature: Key Differences Explained

Gmail renders HTML signatures using the same Blink rendering engine that powers Chrome. This means it handles most modern HTML and CSS properties correctly—with one significant exception: it strips <style> block CSS. Any styles defined in a <style> block or linked stylesheet are removed by Gmail's sanitization process. The rest of your HTML remains, but those elements are unstyled.

The fix for Gmail is inline styles on every element. font-family: Arial, sans-serif; color: #333333; font-size: 14px; — these must appear as attributes on each HTML element, not in a centralized style block. When done correctly, Gmail renders inline-styled HTML signatures reliably.

Gmail's signature installation interface accepts rich text (which is what most users paste into) or HTML (accessible through a source code view in some browsers). When you paste a formatted signature from another source, Gmail converts it to its internal format, which can sometimes alter spacing or strip certain elements. The most reliable method is to install via the HTML source view or through a signature generator that produces Gmail-compatible output.

Gmail also applies its own font overrides in certain contexts—if you use an unusual font family, Gmail may substitute it. Using common system fonts (Arial, Georgia, Helvetica, Tahoma, Times New Roman, Verdana) ensures that the font you specify is the font that renders.

For images in Gmail, base64-embedded images display reliably without triggering any external image loading prompts. External image links also generally load in Gmail—unlike Outlook, Gmail doesn't block them by default—but base64 is still preferable for consistency across all recipients.

Outlook uses the Microsoft Word HTML rendering engine—not a browser engine. This is the source of all Outlook rendering complexity. Word's HTML renderer was designed for print layout, not web content, and its CSS support is significantly limited compared to any browser.

What Outlook supports: basic table layouts, a limited set of inline CSS properties (font-family, font-size, color, background-color, width, height, padding for tables, text-align), and base64-embedded images.

What Outlook doesn't support: CSS grid, flexbox, most position properties, border-radius (the CSS property—this is why circular headshots often appear as squares in Outlook), box-shadow, CSS transitions, and most pseudo-elements. It also ignores max-width on images in some versions and handles line-height inconsistently.

Outlook's default behavior blocks external images. When a recipient opens your email in Outlook, images hosted at external URLs are replaced with broken image placeholders unless the recipient has enabled external image loading for your domain. Base64-embedded images are not external—they're part of the email HTML file—so they display without this restriction.

The practical consequence of Outlook's limitations is that email signatures must be built with table-based layouts and inline styles if they're going to work in Outlook. Any other approach—however correct it is in a web browser—will produce broken output in Outlook. This is not a bug that Microsoft will fix; it's the result of architectural decisions made in how Outlook processes HTML that have been consistent across Outlook 2007 through Outlook 2021.

The image handling differences between Gmail and Outlook are the most practically significant for signature rendering.

Gmail loads external images by default. When you send an email with a signature that links to an image hosted at yourcompany.com/logo.png, Gmail recipients see the logo. This creates a false impression that external image linking works—it does, in Gmail.

Outlook blocks external images by default. The same signature that looks fine for your Gmail contacts appears with broken image icons for your Outlook contacts. Since Outlook is the dominant email client in corporate environments, this means your signature breaks for a large portion of professional recipients.

The solution is base64 encoding: the image data is embedded directly in the HTML as a long string of characters. The image travels with the email and displays regardless of the recipient's image loading settings or what happens to the source URL. Gmail, Outlook, Apple Mail, and all major email clients display base64-embedded images correctly.

File size considerations with base64: a 50KB logo becomes approximately 67KB of base64 text. For a small logo and a headshot, you might add 100-150KB to each email. This is generally acceptable—well within standard email size limits—but it argues for compressing images appropriately before embedding rather than embedding full-resolution originals.

Both Gmail and Outlook have mobile apps for iOS and Android, and their signature rendering on mobile differs from desktop in important ways.

The Gmail mobile app renders HTML signatures similarly to Gmail on desktop—it handles inline styles correctly and displays base64 images. The main difference is screen width: on a phone, a two-column signature layout that's 600px wide extends beyond the screen and requires horizontal scrolling. Single-column signatures or simple two-column layouts with a fixed-width logo column display correctly.

The Outlook mobile app renders HTML signatures with slightly more modern capabilities than Outlook desktop—it doesn't use the Word rendering engine. CSS flexbox and some modern properties work in Outlook mobile that fail in Outlook desktop. However, since you can't know which version of Outlook a recipient uses, building for the most restrictive environment (Outlook desktop) ensures compatibility everywhere.

Both mobile apps display signatures in their native email compose interface. Gmail on iOS lets you configure signatures in the app settings and applies them to new emails. Outlook on iOS also has a signature configuration in app settings. For most users, these mobile signatures are separate from desktop signatures—if you want consistency, you need to configure your signature separately in the mobile app.

A practical mobile testing tip: send a test email to yourself and open it in both the Gmail app and the Outlook app on your phone before finalizing your signature. This catches layout issues that aren't visible in desktop testing.

A signature that works in both Gmail and Outlook is achievable—it just requires adhering to the technical constraints of the more restrictive environment (Outlook). If the signature renders correctly in Outlook, it will render correctly in Gmail. The reverse is not true: a signature optimized for Gmail may fail in Outlook.

The technical requirements for cross-client compatibility: use table-based layout (not div, flexbox, or CSS grid), apply all styles as inline attributes (not style blocks or classes), use base64-embedded images (not external URLs), limit CSS properties to those supported by Outlook's Word rendering engine, use common system fonts, and test in Outlook before finalizing.

For the color accent line that many signatures include (a colored vertical or horizontal line as a visual accent), use a one-cell table with a background color rather than CSS border—Outlook handles table background colors correctly but is inconsistent with CSS borders on non-table elements.

For headshots, render them as square images if you want to guarantee Outlook compatibility. CSS border-radius (which creates circle crops) is not supported in Outlook desktop, so a circular crop in CSS appears as a square in Outlook. Some designers use circular masks at the image level before embedding—this ensures the circular appearance in all clients.

SignatureFox generates signatures that are specifically tested for Outlook compatibility. The output is table-based HTML with inline styles and base64-embedded images—the standard that works across all versions of Outlook and all major email clients.